이 시리즈의 1부에서는 예제 앱을 사용하여 모듈, 도우미, 보기, 컨트롤러 및 경로를 탐색하는 Devise를 소개했습니다.
이 부분에서는 Devise의 고급 사용법, 특히 OmniAuth, API 인증 및 Authtrail의 사용을 살펴보겠습니다.
바로 들어가 보겠습니다!
Ruby용 OmniAuth를 사용한 인증
요즘 여러분이 접하는 거의 모든 웹 애플리케이션은 Twitter, Facebook과 같은 소셜 네트워크부터 Google, GitHub 등에 이르기까지 다양한 인증 제공업체를 통해 로그인할 수 있는 옵션을 제공합니다.
대부분의 경우 이 편리한 다중 공급자 인증은 OmniAuth라는 라이브러리를 통해 제공됩니다. OmniAuth는 여러 외부 공급자와 통합할 수 있는 유연하고 강력한 Ruby용 인증 라이브러리입니다.
다양한 OAuth 공급자에 연결하기 위한 간단하고 통합된 API를 제공합니다. OmniAuth는 사용자에게 소셜 미디어 계정을 사용하여 가입하거나 로그인할 수 있는 옵션을 제공하려는 상황에 특히 유용합니다. OmniAuth를 사용하면 Rails 애플리케이션에 소셜 로그인 기능을 쉽게 추가할 수 있습니다.
Devise gem과 함께 OmniAuth를 사용하면 사용자 인증 및 권한 부여를 관리하는 것이 더욱 쉬워집니다. 외부 공급자 로그인 옵션에 OmniAuth를 사용하는 동시에 Devise에 내장된 인증 기능을 활용할 수 있습니다.
OmniAuth 및 Devise 시작하기
언급한 대로 OmniAuth를 사용하면 여러 타사 인증 공급자와 통합할 수 있습니다. 이 글에서는 GitHub를 사용하겠습니다.
OmniAuth Gem 설치
앱의 Gemfile , 다음 줄을 추가하세요:
OmniAuth 2.0+ gem을 사용하는 경우 다음도 추가해야 합니다.
omniauth-rails_csrf_protection gem은 모든 GET을 보장합니다. OAuth 흐름에 대한 요청이 비활성화됩니다. 또한 OAuth 요청 단계 전에 Rails CSRF 토큰 검증기를 삽입합니다. 이 두 가지 작업은 OAuth 인증 흐름을 겨냥한 교차 사이트 위조 공격을 완화하기 위한 것입니다.
다음으로 bundle install를 실행하세요. 보석을 설치합니다.
새 GitHub OAuth 앱 만들기
이제 GitHub에서 새로운 OAuth 앱을 만들어야 합니다. 이 앱은 필요한 경우 쉽게 취소할 수 있는 인증 권한을 가진 사용자 역할을 합니다.
첫 번째 단계는 GitHub 계정 프로필 아래의 설정 페이지로 이동하는 것입니다. 그런 다음 왼쪽 메뉴에서 '개발자 설정'을 클릭하세요. 새 OAuth 앱을 만들 수 있는 아래와 같은 화면이 표시됩니다.
"새 애플리케이션 등록"을 클릭하면 다음과 같은 화면이 나타납니다:
다음과 같이 양식 세부정보를 입력하세요.
- 애플리케이션 이름 - 새 OAuth 앱에 적절한 이름을 지정하세요.
- 홈페이지 URL - 지금은
http://localhost:3000/을 사용하세요. . 프로덕션에서는 앱의 실제 홈페이지 URL을 사용합니다. - 애플리케이션 설명 - 꼭 필요한 것은 아니지만, 앱이 많고 차별화가 필요한 경우에는 하나쯤 있으면 됩니다.
- 승인 콜백 URL - 이는 필수 입력이며 일반적으로
http://<app-url>/users/auth/<application-provider>/callback와 같은 OAuth 콜백 URL 형식을 따릅니다. . 하지만 Google과 같은 일부 OAuth 제공업체에서는 이 형식을 따르지 않을 수 있으므로 이 점에 유의해야 합니다.
완료되면 "애플리케이션 등록"을 클릭하세요. 다음 화면에서 새로운 앱 비밀을 생성하고 안전한 곳에 적어두세요(한 번만 표시되므로).
Deviise 초기화 구성
Devise 초기화 프로그램 config/initializers/devise.rb을 엽니다. GitHub와 관련된 OmniAuth 섹션으로 이동합니다. 주석 처리될 가능성이 높으므로 주석 처리를 해제하고 새 GitHub OAuth 앱의 ID와 비밀번호로 편집하세요.
OmniAuth 콜백 컨트롤러 생성
Devise 컨트롤러를 이미 생성한 경우 OmniauthCallbacksController를 찾을 수 있습니다. 그에 따라 사용자 정의할 준비가 되었습니다. 해당 항목이 없으면 수동으로 만들고 다음과 같이 편집하세요.
위 코드에 대해 참고할 사항:
from_omniauthUser내부에서 구현할 메서드입니다. 모델.sign_in_and_redirectOAuth 내부의 메소드입니다.
사용자 모델 수정을 위한 마이그레이션 추가
이제 User 모델에 일부 열, 특히 provider을 추가해야 합니다. 열 및 uid 열:
bundle exec rails db:migrate 실행 이 단계를 마무리합니다.
Devise 모델을 완전 인증 가능하게 만들기
여기서 User를 편집해야 합니다. Devise Omniauthable 모듈을 추가하여 모델을 만드세요:
그 뒤에 from_omni_auth를 추가하세요. 방법. 이는 Users::OmniauthCallbacksController에서 호출됩니다. 방금 설정한 것입니다:
이제 한 가지만 더 남았습니다. Devise 뷰에 로그인 링크를 추가하는 것입니다.
로그인 링크 설정
기본적으로 Devise는 사용자 등록 및 로그인 보기에 적절한 공급자의 로그인 링크를 자동으로 추가합니다. 이 링크는 GET을 사용합니다. 하지만 OmniAuth 2.0+에서는 POST를 선호한다는 것을 알고 있습니다. 요청. 따라서 링크를 비활성화하고 POST를 사용하여 링크를 삽입해야 합니다. 요청:
이를 통해 Devise 및 GitHub OAuth 인증을 사용하여 Ruby on Rails 7 앱을 성공적으로 설정했습니다. 여기에서 컴패니언 앱의 전체 소스 코드를 확인할 수 있습니다.
다음으로 Devise를 사용하여 API 호출을 인증하는 또 다른 고급 사용 사례를 살펴보겠습니다.
Ruby용 Devise를 사용한 API 인증
오늘날 사용자가 API를 통해 앱에 연결할 수 있기를 기대하는 것은 드문 일이 아닙니다. 이 섹션에서는 Devise를 사용하여 그러한 사용자 요청을 안전하게 인증할 수 있는 방법을 살펴보겠습니다.
브라우저 기반 인증이 일반적으로 쿠키 기반인 경우 대부분의 API 인증은 헤더에서 전달되는 JSON 웹 토큰(또는 간단히 JWT)이라는 토큰을 통해 이루어집니다.
도움말 :이 섹션에서는 Rails API 전용 앱으로 작업한다고 가정합니다. 계속하려면 rails new app_name --api으로 하나 만드세요.
JWT 기반 인증 흐름
앞서 언급했듯이 API 인증은 JWT 토큰을 기반으로 하며 JWT 기반 인증 흐름이 어떻게 발생하는지 이해하는 것이 중요합니다. 기본적으로 아래에 설명된 일반적인 단계 순서를 따릅니다.
- 사용자 클라이언트가 API 앱을 호출합니다.
- API 앱은 쿠키 대신 사용할 수 있는 인증 토큰인 JWT(JSON 웹 토큰)로 응답합니다.
- 사용자 클라이언트의 후속 요청은
Authorization에서 이 토큰을 사용하여 이루어집니다. 헤더. - 그런 다음 사용자는 Devise '세션 삭제' 작업을 누를 수 있으며, 이로 인해 토큰이 삭제되고 사용자가 로그아웃됩니다.
이제 CORS(교차 원본 리소스 공유)부터 시작하여 이 흐름을 실행해 보겠습니다.
CORS 설정
CORS는 외부 소스의 요청을 허용하도록 API 앱을 설정합니다. CORS는 애플리케이션에서 외부 요청을 처리하는 방법을 정의하는 HTTP 기반 보안 정책입니다. 기본적으로 CORS는 초기 요청과 다른 도메인에서 시작된 모든 요청(즉, 다른 "원본"에서 오는 요청)을 차단합니다.
CORS를 적절하게 처리하기 위해 멋진 gem rack-cors을 사용하겠습니다. . Gemfile에서 , 아래 줄의 주석 처리를 제거한 다음 bundle install을 실행하세요. :
또한, 해당 CORS 초기화 파일을 열고 아래와 같이 수정하세요:
방금 수행한 작업에 대한 몇 가지 중요한 참고 사항:
origins "*"- 간단히 말해서 API 앱이 이제 다른 소스로부터 요청을 받을 수 있다는 의미입니다.expose: %w[Authorization Uid]- 기본적으로rack-corsgem은 인증 및 UID 헤더를 노출하지 않지만 인증 토큰을 전달할 것이기 때문에 필요합니다.
완료되었으면 Devise와 함께 제공되는 Devise-JWT gem을 설치해 보겠습니다.
Rails 앱에 Devise 및 Devise-JWT Gem을 추가하세요
devise-jwt gem은 JWT 토큰으로 작업할 수 있게 해주는 Devise의 확장입니다. Gemfile에 보석을 추가하세요 을 누른 다음 bundle install를 실행하세요. :
Devise 설치 생성기 bundle exec rails g devise:install 실행 .
모델 생성 및 구성
두 가지 모델, 즉 일반 Devise 사용자 모델(bundle exec rails g devise User)을 설정해야 합니다. ) 및 해지 전략에 사용할 모델(즉, 사용자가 API에서 로그아웃하는 방법):
JWT 토큰 인증 가능 모듈을 추가하고 두 번째 모델인 JwtDenylist를 사용하도록 토큰 취소 전략을 정의하여 API 인증을 위한 일반 Devise 사용자 모델을 수정합니다. :
다음으로, 폐기 전략과 사용될 폐기 테이블을 참조하여 두 번째 모델을 구성합니다.
다음 섹션에서는 토큰 취소와 그것이 필요한 이유에 대해 간략히 설명하겠습니다.
토큰 취소의 중요성
토큰 취소가 중요한 이유는 무엇입니까? JWT 토큰은 상태 비저장(Stateless)이기 때문입니다. 서버는 서명 외에는 아무것도 모릅니다. 이러한 시나리오에서는 서버가 해당 토큰을 취소하여 사용자를 로그아웃할 방법이 없습니다. 개별 토큰을 취소할 수 있는 방법이 없으므로 하나를 구축하고 서버에 이를 사용하도록 지시해야 합니다.
토큰을 취소할 때 내부적으로 실제로 일어나는 일은 토큰의 고유한 부분인 jti입니다. (JWT ID)를 정의된 해지 전략에 따라 추출하여 사용합니다.
물론 이는 토큰 철회 전략이 무엇인지에 대한 또 다른 질문을 제기합니다. 간단히 말해서 서버에서 토큰 취소를 처리하는 방법에 대한 정의입니다. 세 가지 기본 취소 전략이 있습니다:
- JTIMatcher 전략 - 여기서는 "jti"라는 고유 열이 사용자 모델에 추가되며 이는 해지 테이블 역할도 합니다. 사용자가 요청할 때마다
jti헤더의 내용은 저장된 토큰과 일치하며 일치하는 항목이 발견된 경우에만 액세스가 허용됩니다. - 거부 목록 전략 - 이 경우
jti및 토큰 만료(exp취소된 토큰 수)는 데이터베이스 테이블에 저장됩니다. 사용자가 요청할 때마다 이 테이블을 통해 사용자의 현재 토큰jti을 비교하는 검사가 이루어집니다. 데이터베이스의 취소된 항목에 대해. 일치하는 항목이 발견되면 해당 사용자의 요청이 거부됩니다. - 허용 목록 전략 - 이 전략은 JWT ID를 저장하는 테이블이 사용자 토큰을 저장하는 다른 테이블과 일대다 관계에 있다는 점을 제외하면 첫 번째 전략과 유사합니다. 요청이 있을 때마다 사용자의
jti허용 목록 테이블에 저장된 항목은 토큰과 함께 일치 테이블에 저장된 항목과 일치됩니다. 일치하는 항목이 있는 경우에만 액세스가 허용됩니다.
분명히 이는 토큰 취소에 대한 매우 단순화된 개요이며 여기에서 자세한 내용을 알아볼 수 있습니다.
JWT 토큰에 대한 서명 키 설정
사용자와 요청을 인증하기 위해 보안 토큰을 사용할 것이므로 서명 방법이 필요합니다. 이것이 우리의 비밀 키가 들어오는 곳입니다. Rails 비밀 키인 secret_key_base와 다른 새 키를 생성하는 것이 좋습니다. .
bundle exec rake secret 실행 고유한 키를 생성하려면 다음 키를 포함하도록 Devise 초기화 프로그램을 편집하세요:
마지막으로 컨트롤러를 설정해 보겠습니다.
컨트롤러 설정
API 인증을 위한 Devise를 구현하는 마지막 단계는 컨트롤러를 설정하는 것입니다. 단순화를 위해 두 개의 컨트롤러를 설정하겠습니다. 하나는 등록을 처리하고 다른 하나는 세션을 처리합니다.
등록 컨트롤러부터 시작하여 수동으로 생성해 보겠습니다.
이 컨트롤러에서 일어나는 일은 다음과 같습니다:
- JSON으로 요청에 응답하도록 구성합니다.
respond_with를 지정합니다. 등록 성공 또는 실패 결과를 반환하는 작업입니다.
이제 세션 컨트롤러의 경우:
등록 컨트롤러와 마찬가지로 여기서는 컨트롤러가 JSON으로 응답하도록 지정합니다. respond_with도 정의합니다. 사용자가 성공적으로 로그인했을 때의 작업 및 respond_to_on_destroy 사용자 로그아웃을 처리합니다.
그리고 이를 통해 Devise 및 JWT 토큰으로 구동되는 작동하는 API 인증 흐름이 있어야 합니다!
마지막 섹션에서는 Devise 및 Authtrail을 사용하여 사용자 로그인을 추적하는 방법을 간략하게 살펴보겠습니다.
Authtrail로 Devise 로그인 추적
누군가 자신의 계정에 로그인할 때마다 IP 주소 및 로그인 타임스탬프와 같은 세부정보가 포함된 알림 이메일을 앱 사용자에게 보내고 싶다고 가정해 보겠습니다. 어떻게 이를 달성할 수 있나요?
사용자 로그인을 추적한 다음 사용자에게 보내는 알림 이메일에서 해당 정보를 사용해야 합니다. 하지만 먼저 사용자 로그인을 추적하는 방법이 필요합니다. 이는 Devise와도 잘 어울리는 Authtrail이라는 멋진 보석을 사용하여 수행할 수 있습니다.
Authtrail 설치
첫 번째 단계는 bundle add authtrail로 gem을 설치하는 것입니다. . 또한 앱 데이터베이스에 이메일, IP 주소 등 사용자 식별 정보를 저장하게 되므로 Lockbox 및 Blindindex gem을 조합하여 프로덕션에서 이 데이터를 암호화하는 것이 좋습니다.
다음으로, Authtrail 생성기를 실행하여 초기화 프로그램과 로그인 데이터를 저장할 관련 테이블 마이그레이션을 생성합니다:
인증 추적 작동 방식
사용자가 로그인을 시도할 때마다 다음과 같은 중요한 세부정보가 포함된 새로운 인증 추적 기록이 생성됩니다.
- 사용된 로그인 이메일 주소
- 로그인 성공 여부
- 로그인 실패 이유(로그인에 실패한 경우)
- 사용자의 IP 주소,
referrer, 그리고 더 많은 것
그러면 이 정보를 원하는 대로 사용할 수 있습니다. 예를 들어, 사용자에게 이메일 및 IP 주소 정보가 포함된 알림 이메일을 보내 해당 계정에 로그인 시도가 있었음을 알릴 수 있습니다.
가능한 모든 가능성을 확인하려면 Authtrail의 문서를 살펴보세요.
마무리
이 시리즈에서는 Devise gem에 대해 자세히 살펴보았습니다.
먼저 모듈, 도우미, 뷰, 컨트롤러 및 경로의 작동 방식을 포함하여 Devise의 기본 사항을 파악했습니다. 두 번째이자 마지막 부분에서는 Devise를 OAuth, Authtrail 및 API 인증과 함께 사용하는 방법을 살펴보았습니다.
이 시리즈가 Devise 인증에 대한 모든 유용한 가이드가 되기를 바랍니다.
즐거운 코딩 되세요!
추신 Ruby Magic 게시물이 보도되는 즉시 읽으려면 Ruby Magic 뉴스레터를 구독하고 단 하나의 게시물도 놓치지 마세요!