Documents

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 ServerResource Server 간의 상호 작용interaction은 이 스펙의 범위를 벗어난다. Authorization ServerResource Server 와 동일하거나 별도의 서버일 수 있다. 단일 Authorization Server 는 여러 Resource Server 에서 승인된 Access Token 을 발급할 수도 있다.

Protocol Flow

Figure 1: Abstract 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
  1. 클라이언트가 사용자의 데이터에 접근하기 위해 권한을 요청한다.

  2. 접근에 동의함을 증명하는 권한 부여 동의서(Authorization Grant)를 발급한다. REC 6749에서는 4가지 유형의 권한 부여 동의서를 정의한다.

  3. 권한 부여 동의서를 제출하여 접근 토큰을 요청한다. 접근 토큰은 사용자 데이터를 잠근 자물쇠를 여는 열쇠이다.

  4. 권한 부여 동의서를 확인하여 사용자가 동의한 데이터에 대한 정보가 담긴 접근 토큰을 제공한다.

  5. 접근 토큰을 제출하여 사용자 데이터를 요청한다.

  6. 사용자 데이터를 제공한다. 이때 앱이 제출한 접근 토큰이 유요함을 확인하고, 접근 토큰의 정보를 확인하여 제공할 데이터 항목 범위 및 유효기간이 정해진다.

Authorization Grant

Authorization Code

Figure 3: Authorization Code Flow
@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

Figure 4: Implicit Grant Flow
@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

Figure 5: Resource Owner Password Credentials Flow
@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

Figure 6: Client Credentials Flow
@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