Oauth2
OAUTH 2.0
Why?
- 상대적으로 간편하고 안전하다.
- 현재 소셜 인증 등으로 가장 널리 사용되는 방법이다.
목적
- 다양한 클라이언트 기기들의 인증을 간단히 할 수 있다.
- 제 3의 서비스에서 리소스 소유자의 인증을 거쳐 리소스 서버에 리소스를 요청할 수 있다.
인증 방법
- authorization code
- implicit
- resource owner password-credentials
- client credentials
네가지 방법이 있는데, 그 중 SPA에서는 implicit 방법이 적절하다.
Implicit
- 브라우저 기반(JS)에서 직접 코드를 획득하는 방법
- 리소스 오너는 브라우저 등을 통해 액세스 토큰을 바로 획득함
- 클라이언트는 리소스 오너로부터 받은 액세스 토큰을 리소스 서버로 전달함
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
Note: The lines illustrating steps (A) and (B) are broken into two
parts as they pass through the user-agent.
Figure 4: Implicit Grant Flow
용어 정의
Resource Owner
일반적인 사용자
Client
서비스 제공자
Authorization Server
인증을 담당하는 서버 (ex: 깃헙 인증 서버)
Resource Server
리소스를 가지고 있고 클라이언트에게 제공해 주는 서버 (ex: 깃헙 데이터 서버)
등록
OAuth를 이용해서 Resource Server에 접속하기 위해서는 우선 Resource Server에 등록하는 과정이 필요하다.
Create app
-----------------------------------------------------
Client ID 1
Client Secret 2
Authorized redirect URIs http://example.com/callback
Resource Owner의 승인
OAuth의 첫번째 절차로 Resource Owner가 Resource Server에게 Client의 접근을 승인한다는 것을 알려줘야 한다.
[예시]
1. 깃허브로 로그인 버튼 클릭
2. 로그인 창에서 사용자 정보 입력
3. GET https://github.com/login/oauth/authorize?client_id={client_id}&redirect_uri=http://example.com/callback
4. Resource Server은 등록한 client_id, redirect_uri와 요청의 내용 비교
5. scope, 요청 허용하는지 확인하는 절차 진행하고 서버에 scope 내용도 함께 저장
Resource Server의 승인
Resource Server는 Client가 등록된 Client가 맞는지 확인하기 위해서 Resource Owner을 통해서 Client에게 Authorization code(임시 비밀번호)를 전달한다. 이 값을 받은 Client는 이 값과 Client secret의 값을 Resource Server로 전송해서 Client의 신원을 Resource Owner에게 증명한다.
[예시]
1. Resource Server가 Authorization code를 query로 보내서 사용자는 알지도 못하는 사이 이동한다.
2. client도 Authorization code를 저장하게 되고 resource server에 authorization code와 client_secret 정보 등을 담아서 요청을 보낸다.
3. resource server가 client secret과 authorization code를 비교해서 일치한지 확인한다.
Access token
OAuth의 핵심인 access token을 발급한다.
[예시]
1. POST https://github.com/login/oauth/access_token
(req.body: code, client_id, client_secret)
2. resource server는 또다시 인증을 하지 않기 위해 authorization code를 지우고, access token을 client에게 보낸다.
3. client는 access token을 받아서 DB 등에 저장한다.
4. 다음에 사용자가 api 요청 보낼 때 저장된 access token을 재사용한다.