OAuth 2.0

Introduction

애플리케이션 활용 시, 사용자가 해당 어플리케이션에 계정 정보를 제공하지 않고 신뢰 가능한 외부 어플리케이션의 Open API를 사용해 인증 과정을 처리하는 방식

OAuth가 보편화되기 전, 타 어플리케이션의 계정 정보가 필요할 경우 직접적으로 계정 정보(PW 등)를 요구하기도 해 보안 우려 존재.

- 사용자: 어플리케이션을 신뢰 불가
- 어플리케이션: 외부 어플리케이션의 계정정보에 대한 모든 책임
- 외부 어플리케이션: 어플리케이션 신뢰 불가

복잡하던 OAuth 1.0을 개량하여 간소화되고 유연성을 높인 OAuth 2.0이 현재 널리 사용중에 있음.

---

OAuth 2.0 Flow

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                    Abstract Protocol Flow


[Client]: Resource 요청하는 Application
[Resource Owner]: Client가 사용하려는 계정의 Owner
[Authorization Server]: 사용자 Authorization 서버 
[Resource Server]: Resource 관리 서버

---

[A.] Resource Owner에게 권한 요청

https://account.test.com/auth?
    client_id = asd123&
    redirect_uri = https://test.com/callback&
    scope = profile&
    response_type = code&
    state = zxcv


[client_id]: 요청을 송신하는 Client의 ID를 명시한 파라미터
[redirect_uri]: Resource Owner가 인증 프로세스 마칠 시 리다이렉트될 주소
[scope]: Client가 요청하는 권한 명시
[response_type]: 서버에게 요청할 Grant Type. 보편적으로 Code 사용
[state]: 보안을 위한 설정 값, 이후 응답에서 이 값이 유지되어야 함

[B.] Resource Owner가 권한 요청 검증, 권한 승인을 response로 보냄

https://test.com/callback?
    code = 1hfg31jg312kj3g&
    state = zxcv


[code] : 이전 요청에서 response_type 파라미터의 결과

[C.] Client는 Auth Server에 권한 승인 제시하여 Access Token 요청

POST account.test.com/token
Content-Type: application/x-www-form-urlencoded

code = 1hfg31jg312kj3g&
client_id = asd123&
client_secret = secret123&
grant_type = authorization_code


[Content-Type]: Client가 Token End Point에 보내는 모든 파라미터는 application/x-www-form-urlencoded 형식이어야 함
[client_secret]: 처음 Client가 Client_id와 함께 발급받은 값
[grant_type]: Grant의 종류를 나타냄. 통상적으로 Authorization_code 사용

[D.] Auth Server가 권한 검증 후, Access Token 제공

{
    "access_token" : "kh345l2j52n32l4kj",
    "expires_in" : "123456",
    "token_type" : "Bearer",
}


[access_token] : Client가 인가를 위임 받았음을 증명하는 토큰. Resource Server와 통신할 때 사용
[expire_in] : 토큰의 유효 시간
[token_type] : 토큰의 종류. Bearer, MAC 등이 존재

[E.] Access Token 사용해 서버에서 보호된 리소스 요청

GET api.test.com/endpoint
Autorization : Bearer kh345l2j52n32l4kj


token을 type과 함께 Authorization 헤더로 전달

[F.] Res Server가 Token 검증 후 요청 제공

---

Authorization Grant(Code)와 Access Token을 분리하는 이유

• Access Token의 노출 최소화를 위해
• Authorization Code는 사용자가 브라우저를 통해 접근하기 때문에 프론트 채널을 사용해야함
• Access Token과 Authorization Code 로직을 분리하지 않으면 토큰도 프론트 채널에서 이동

Back Channel

• 굉장히 안정적인 통신 구간.
• 사용자 혹은 제 3자의 개입이 있을 가능성이 희박해 위변조 가능성 또한 희박한 통신구간.
• OAuth 2.0에선 Auth Server과 Client간의 통신 구간.

Front Channel

• 위변조의 가능성이 존재하는 통신 구간.
• 사용자의 브라우저를 거치는 통신을 의미.