OAuth2 인증 방식
Session 인증 방식은 애플리케이션 내 로그인 과정을 통해 서버측에 저장된 메모리 또는 데이터베이스의 유저 정보의 세션 정보를 취득하고 세션이 만료되기 전까지 서비스를 이용할 수 있는 방식입니다. Session 인증 방식은 서비스가 다수의 서버로 구축될 경우, 세션 공유의 문제가 발생할 수 있기 때문에 Sticky Session, Session Clustering, 별도의 세션 저장소(Redis) 구축 등의 방법을 사용합니다.
OAuth 인증방식은 Session 사용하지 않고 Token 인증 방식을 사용하기 때문에 Session 인증 방식의 문제점을 해결함과 동시에 여러 서비스들을 통합거나 구글, 페이스북, 네이버, 카카오 등의 대형 포털 사이트 계정으로 간편 로그인을 이용할 수 있도록 하여 사용자의 편리성을 도모할 수 있습니다.
OAuth 2.0(The OAuth 2.0 Authorization Framework)
RFC6749 문서에 정의되어 있으며, Resource Owner(사용자)가 Client(서비스 서버)를 통해 Authorization Server에 Access Token을 발급받고 Access Token으로 Resource Server의 리소스(계정 정보 등)에 접근하는 일련의 과정들을 인터페이스 해놓은 프레임워크 입니다.
OAuth 2.0 주요 용어
| 용어 | 설명 |
|---|---|
| Resource Owner | 요청할 리소스의 주인 즉 사용자를 의미합니다. |
| Client | 사용자가 이용하려는 서비스로 현재 접속한 사이트를 의미하며 리소스를 이용하는 주체입니다. |
| Authorization Server | 접속한 사이트에서 구글 등의 간편로그인을 할 경우 구글에 인증을 받기 위한 서버입니다. |
| Resource Server | 사용자의 정보를 제공해주는 서버로 인증 후 이용할 수 있습니다. |
| Access Token | Authorization Server에서 인증을 받으면 발급해주는 토큰(인증서 같은 개념)입니다. |
| Refresh Token | Access Token이 만료되면 사용자가 다시 인증받을 필요 없이 Authorization Server로 Access Token을 받을 수 있도록 해주는 토큰 입니다. |
Refreshing an Expired Access Token
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
OAuth2.0은 Access Token을 얻기 위한 4가지 방법을 제공합니다.
- Authorization Code Grant
- Implicit Grant
- Resource Owner Password Credentials Grant
- Client Credentials Grant
1. Authorization Code Grant
Client가 Authorization Server에서 Access Token을 발급 받기 위해서 Resource Owner가 승인(로그인) 후 전달 받은 Authorization Code를 사용하는 방식으로 가장 권장 되는 방식입니다. (Refresh Token을 사용할 수 있습니다.)
Authorization Request (application/x-www-form-urlencoded 형식으로 요청)
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
| parameter | required | value |
|---|---|---|
| response_type | 필수 | code 고정값 사용 |
| client_id | 필수 | client 고유ID |
| redirect_uri | 선택 | Authorization Server로부터 응답받을 url |
| scope | 선택 | profile, email 등 접근하려는 resource 범위를 지정 |
| state | 권장 | 요청 위변조를 방지하기 위해 랜덤한 매개 변수 값 |
Access Token Response
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
Authorization Code Flow
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
- Client는 Client 식별자, scope, local state, redirection URI를 Authorization Server의 endpoint로 전송하고, Authorization Server는 액세스 요청을 승인 또는 거절하여 사용자 에이전트를 다시 보냅니다.
- Authorization server가 Resource Owner(사용자)를 인증하고 Resource Owner가 Client의 액세스 요청 허용 또는 거부합니다.
- Resource Owner가 권한을 부여한다고 가정할 경우 Authorization server는 제공된 redirection URI로 authorization code, local state가 포함된 사용자 에이전트를 Client에게 리다이렉트합니다.
- Client는 Authorization server를 인증한 후 authorization code와 Redirection URI로 Authorization server에게 Access Token을 요청합니다.
- Authorization server는 클라이언트를 인증하고 authorization code를 검증하며 3번 단계에서 사용된 redirection URI와 일치 하는지 확인합니다. 모든 검증이 끝나면 Authorization server는 Access Token 및 선택적으로 Refresh Token을 Response합니다.
2. Implicit Grant
암시적인 승인방식은 Javascript 등과 같은 브라우저에서 동작하는 Client에서 사용하며 Authorization Code 인증 과정을 생략하고 인증 후 Authorization server가 Client의 Redirect URL로 Access Token을 Query String으로 넘겨주는 방식이기 때문에 정보가 노출될 위험이 있습니다. 따라서 앱 안에서 동작하는 웹 뷰 등과 같이 노출위험이 적은 곳에서 사용합니다. (Refresh Token을 사용할 수 없습니다.)
Authorization Request (application/x-www-form-urlencoded 형식으로 요청)
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
| parameter | required | value |
|---|---|---|
| response_type | 필수 | token 고정값 사용 |
| client_id | 필수 | client 고유ID |
| redirect_uri | 선택 | Authorization Server로부터 응답받을 url |
| scope | 선택 | profile, email 등 접근하려는 resource 범위를 지정 |
| state | 권장 | 요청 위변조를 방지하기 위해 랜덤한 매개 변수 값 |
Access Token Response
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600
Implicit Grant Flow
+----------+
| 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.
3. Resource Owner Password Credentials Grant
Resource Owner(사용자)의 자격증명(사용자이름 및 비밀번호)로 Access Token을 얻는 방법으로 높은 신뢰성이 있는 클라이언트에만 적용할 수 있는 방법입니다.
(Refresh Token을 사용할 수 있습니다.)
Authorization Request (application/x-www-form-urlencoded 형식으로 요청)
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
| parameter | required | value |
|---|---|---|
| grant_type | 필수 | password 고정값 사용 |
| username | 필수 | 사용자 이름(ID) |
| password | 필수 | 사용자 비밀번호 |
| scope | 선택 | profile, email 등 접근하려는 resource 범위를 지정 |
Access Token Response
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
Resource Owner Password Credentials Flow
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
4. Client Credentials Grant
클라이언트의 자격 증명(또는 지원되는 다른 인증 방법)만을 사용하여 Access Token을 요청하는 방법입니다. (Refresh Token을 사용할 수 없습니다.)
Authorization Request (application/x-www-form-urlencoded 형식으로 요청)
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
| parameter | required | value |
|---|---|---|
| grant_type | 필수 | client_credentials 고정값 사용 |
| scope | 선택 | profile, email 등 접근하려는 resource 범위를 지정 |
Access Token Response
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
Client Credentials Flow
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
참고자료: RFC6749
댓글남기기