Rails 8 인증 제너레이터를 활용한 API 전용 애플리케이션 사용자 인증 구현

Rails Generator Authentication in API-only apps - Avo

작성자
Ruby Weekly
발행일
2025년 09월 22일

핵심 요약

  • 1 Rails API 전용 앱의 주요 인증 방식(세션, JWT, 베어러 토큰)을 비교하고 각 방식의 장단점 및 적합한 사용 사례를 분석합니다.
  • 2 Rails 8 인증 제너레이터를 API 모드에 맞게 토큰 기반 인증으로 전환하는 방법을 설명하며, `has_secure_token`과 `authenticate_with_http_token` 활용법을 상세히 다룹니다.
  • 3 로그인, 회원가입, 로그아웃, 비밀번호 재설정 기능 구현과 리소스 보호, 그리고 프론트엔드 연동을 위한 CORS 설정까지 전체적인 API 인증 흐름을 안내합니다.

도입

단일 페이지 애플리케이션(SPA)의 복잡성을 넘어 Hotwire가 인터랙티브 Rails 애플리케이션의 대안으로 부상했지만, 모바일 앱, 프론트엔드 프레임워크에 익숙한 팀 또는 다중 플랫폼 애플리케이션과 같은 특정 사용 사례에서는 API 전용 Rails 앱을 구축하는 것이 여전히 합리적입니다. 본 문서에서는 Rails 8의 인증 제너레이터를 활용하여 API 전용 앱에 사용자 인증 기능을 추가하는 방법을 학습하고, 다양한 API 인증 접근 방식의 장단점을 심층적으로 분석합니다.

API 전용 애플리케이션을 위한 인증 방식은 크게 세 가지로 나눌 수 있으며, 각 방식은 고유한 장단점을 가집니다.

API 인증 접근 방식

세션 기반 인증

  • 설명: 전통적인 방식으로, 유효한 자격 증명으로 인증 후 사용자 및 세션 정보를 포함하는 암호화된 쿠키를 반환합니다.
  • 장점: 보안 쿠키에 세션 저장(XSS 공격 위험 감소), 서버 관리 세션 상태(계정 삭제 시 모든 세션 종료 가능), Rails 기본 기능 활용.
  • 단점: 모바일 앱과의 호환성 부족, 동일 도메인 요구사항, 세션 오버헤드(모든 요청에 DB/캐시 조회 필요), 타사 통합 제한.

JSON 웹 토큰 (JWT)

  • 설명: 사용자 정보와 인증 데이터를 자체 포함 토큰에 인코딩하는 무상태 인증 방식입니다. 토큰은 헤더, 페이로드, 서명으로 구성됩니다.
  • 장점: 무상태(서버 측 세션 저장 불필요), DB 조회 불필요, 모바일 앱 친화적.
  • 단점: 보안 고려사항(토큰 탈취 시 위험), 로그아웃 복잡성(토큰 블랙리스트 필요), 만료 관리(토큰 갱신 메커니즘 필요).

베어러 토큰

  • 설명: 사용자에게 무작위 토큰을 생성하여 DB에 저장하고, 클라이언트가 이 토큰을 Authorization: Bearer <token> 헤더와 함께 사용하여 요청하는 무상태 방식입니다. JWT와 달리 토큰은 불투명하며 사용자 정보를 직접 포함하지 않습니다.
  • 장점: DB를 통한 즉각적인 토큰 취소, 보안 이점(사용자 데이터 노출 없음, 토큰 사용 추적 가능), 플랫폼 간 유연성.
  • 단점: 모든 요청에 DB 조회 필요(성능 문제 가능), XSS 취약성(localStorage 저장 시), 토큰 관리(만료, 로테이션, 정리).

Rails 8 Auth API 모드 구현

본 문서에서는 쿠키와 JWT의 중간 지점으로서 Rails 인증과 잘 통합되는 토큰 기반 인증을 사용합니다.

애플리케이션 설정

  1. rails new --api 명령으로 API 전용 Rails 앱 생성.
  2. bin/rails generate authentication 명령으로 인증 제너레이터 실행.
  3. bin/rails generate migration add_token_to_sessions token:uniq 명령으로 sessions 테이블에 token 필드 추가.
  4. Project 모델 생성 및 UserProject 간 관계 설정.

Session 모델 및 Authentication Concern 수정

  1. Session 모델에 has_secure_token :token 추가하여 토큰 자동 생성.
  2. Authentication concern 수정:
    • find_session_by_cookiefind_session_by_token으로 변경.
    • authenticate_with_http_token을 사용하여 요청 헤더에서 토큰 추출.
    • require_authentication 메서드를 수정하여 세션이 없으면 unauthorized 응답 렌더링.
    • start_new_session_forterminate_session 메서드 수정.
  3. ApplicationControllerActionController::HttpAuthentication::Token::ControllerMethods 모듈 포함.

컨트롤러 구현 (로그인, 회원가입, 비밀번호 재설정)

  1. V1::SessionController 구현: create 액션에서 사용자 인증 후 토큰 반환, destroy 액션에서 세션 종료.
  2. V1::RegistrationsController 구현: create 액션에서 사용자 생성 및 세션 토큰 반환. ActiveRecord::RecordNotUnique 예외 처리.
  3. V1::PasswordsController 구현: create 액션에서 비밀번호 재설정 이메일 전송, update 액션에서 토큰을 통해 사용자 확인 후 비밀번호 업데이트 및 관련 세션 모두 파기.

리소스 보호 및 프론트엔드 연동

  • allow_unauthenticated_access가 명시되지 않은 리소스는 기본적으로 보호됩니다.
  • V1::ProjectsController와 같은 리소스 컨트롤러에서 current_user.projects를 통해 인증된 사용자의 데이터에 접근할 수 있습니다.
  • 프론트엔드 앱과의 통합을 위해 rack-cors 젬을 사용하여 CORS를 설정하고, 성공적인 로그인 후 받은 토큰을 저장하여 후속 요청에 사용합니다.

결론

Rails API 전용 앱에서 인증을 처리하는 다양한 접근 방식은 각각의 장단점을 가지고 있으며, 애플리케이션의 특정 요구사항에 따라 신중하게 고려되어야 합니다. 세션 기반 인증은 동일 도메인 브라우저 SPA에 적합하지만 모바일 앱에는 한계가 있고, JWT는 무상태 인증으로 모바일 앱에 유용하나 보안 및 토큰 관리에 복잡성이 따릅니다. 반면, 베어러 토큰은 DB 제어 방식의 취소 기능과 향상된 보안을 제공하며, 모든 요청에 DB 조회가 필요하다는 점을 고려해야 합니다. Rails 8 인증 제너레이터는 HTTP 토큰 인증을 사용하도록 수정하여 API 전용 모드에 효과적으로 적용될 수 있으며, `has_secure_token`을 통한 토큰 생성, `authenticate_with_http_token`을 통한 토큰 유효성 검사, 그리고 등록, 로그인, 로그아웃, 비밀번호 재설정 컨트롤러 구축이 핵심입니다. 이러한 방법을 통해 프로젝트에 필요한 인증 기능을 성공적으로 구현할 수 있을 것입니다.

댓글 0

댓글 작성

0/1000
정중하고 건설적인 댓글을 작성해 주세요.

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!