OAuth
인증(Authentication)과 권한 부여(Authorization)의 필요에 의해..
Roles
OAuth는 4가지 역할을 정의한다. :
- Resource Owner
-
보호 자원protected resource에 접근하는 권한을 부여한다.
Resource Owner
가 개인일 경우 이를 end-user 라고도 한다. - Resource Server
-
보호 자원을 호스팅하는 서버로, Access Token 을 사용하여 보호 자원 요청을 수락하고 적절한 응답을 한다.
- Client
-
Reqource Owner
를 대신하여 보호 자원에 접근을 요청하는 어플리케이션이다. - Authorization Server
-
성공적으로
Resource Owner
를 인증(authenticating)하고 authorization을 얻은 이후Client
에게 Access Token 을 발급한다.
Authorization Server
와 Resource Server
간의 상호 작용interaction은 이 스펙의 범위를 벗어난다. Authorization Server
는 Resource Server
와 동일하거나 별도의 서버일 수 있다.
단일 Authorization Server
는 여러 Resource Server
에서 승인된 Access Token 을 발급할 수도 있다.
Protocol Flow
@startuml
ditaa
+--------+ +---------------+
| |--(1)- Authorization Request ->| Resource |
| | | Owner |
| |<-(2)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(3)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(4)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(5)----- Access Token ------>| Resource |
| | | Server |
| |<-(6)--- Protected Resource ---| |
+--------+ +---------------+
@enduml
-
클라이언트가 사용자의 데이터에 접근하기 위해 권한을 요청한다.
-
접근에 동의함을 증명하는 권한 부여 동의서(Authorization Grant)를 발급한다. REC 6749에서는 4가지 유형의 권한 부여 동의서를 정의한다.
-
권한 부여 동의서를 제출하여 접근 토큰을 요청한다. 접근 토큰은 사용자 데이터를 잠근 자물쇠를 여는 열쇠이다.
-
권한 부여 동의서를 확인하여 사용자가 동의한 데이터에 대한 정보가 담긴 접근 토큰을 제공한다.
-
접근 토큰을 제출하여 사용자 데이터를 요청한다.
-
사용자 데이터를 제공한다. 이때 앱이 제출한 접근 토큰이 유요함을 확인하고, 접근 토큰의 정보를 확인하여 제공할 데이터 항목 범위 및 유효기간이 정해진다.
Authorization Grant
Authorization Code
@startuml
ditaa
+----------+
| 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)
@enduml
Implicit
@startuml
ditaa
+----------+
| 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 |
| |
+---------+
@enduml
Resource Owner Password Credentials
@startuml
ditaa
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
@enduml
Client Credentials
@startuml
ditaa
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
@enduml
Etc
- User
-
서비스 제공자와 소비자를 사용하는 계정을 가지고 있는 개인
- Consumer
-
Open API를 이용하여 개발된 OAuth를 사용하여 서비스 제공자에게 접근하는 웹사이트 또는 애플리케이션
- Service Provider
-
OAuth를 통해 접근을 지원하는 웹 애플리케이션(Open API를 제공하는 서비스)
- Consumer Secret
-
서비스 제공자에서 소비자가 자신임을 인증하기 위한 키
- Request Token
-
소비자가 사용자에게 접근권한을 인증받기 위해 필요한 정보가 담겨있으며 후에 접근 토큰으로 변환된다.
- Access Token
-
인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해서 보호된 자원에 접근하기 위한 키를 포함한 값.
- JWT
-
11