[인증/인가] OAuth 정리

OAuth 참여자

• Resource Owner, User(사용자)
• Service Provider(카카오, Github...)
• Client, Consumer(우리가 만드는 서비스)

OAuth 참여자의 역할

Resource Owner

• Service Provider에 계정이 존재하며,
• Client를 이용하려는 사용자.

Service Provider

• Authorization Server(인증서버)

  • User를 인증하고, Client를 인증하는 서버

• Resource Server(리소스 서버)

  • Open API를 제공하는 서버

Client

• OAuth인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션, 웹 서비스

OAuth의 흐름

     +--------+                               +---------------+
     |        |--(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 ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

출처: https://tools.ietf.org/html/rfc6749

OAuth의 흐름 Detail

1. Service Provider에 Client 등록하기

   • Client ID
     • 우리가 만드는 애플리케이션의 식별자
   • Client Secret
     • 우리가 만드는 애플리케이션의 비밀번호
   • Authorized redirect URIs
     • Authorization Code를 전달 받을 서버의 위치
     • 다른 서버에서 요청하면 무시하기 위해서

2. Resource Owner는 Client에 로그인할 수 있는 페이지 요청

   • 카카오로 로그인하기, Github로 로그인하기 등...

       htttps://Service Provider.com/
         ?client_id=<애플리케이션 식별자>
         &scope=<권한요구범위>(email...)
         &redirect_url=<애플리케이션서버/auth/kakao/callback>

3. Resource Owner는 Service Provider에 로그인 및 권한 승인

   • Service Provider는 Client ID와 redirect URIs가 일치하는 지 확인한다.
   • Service Provider는 Resource Owner의 권한 허용 범위를 기록한다.

4. Service Provider는 Resource Owner에게 Authorization Code(임시 비밀번호)를 전송한다.

   • Service Provider는 Resource Owner에게 redirect URI를 전송한다.

   • 리다이렉트 된다

     Location: 애플리케이션서버/auth/kakao/callback?code=(임시비번)

5. Client는 Service Provider에게 AccessToken을 발급받기 위해 요청한다.

    htttps://Service Provider.com/
        ?grant_type=authorization code
        &code=<임시비번>
        &client_id=<애플리케이션_식별자>
        &scope=<권한요구_범위>(email...)
        &redirect_url=<애플리케이션서버/auth/kakao/callback>
        &client_secret=<Client의_비번>

6. Service Provider는 Client에게 AcessToken(&RefreshToken)을 발급한다.

   • AcessToken을 DB등에 저장한다.
   • AcessToken은 제공자마다 만료기간이 다양하다.

7. Client는 AcessToken을 이용하여 Service Provider의 Resource Server를 이용할 수 있다.

   • Url Query에 AccessToken을 입력

       GET https://www.kakao.com/drive/v2/files?access_token=<access_token>

   • Header에 AccessToken을 입력(추천)

       GET /drive/v2/files HTTP/1.1
       Authorization: Bearer <access_token>

cf. Refresh Token

• AccessToken을 새로 발급받기위한 Token이다.

• Service Provider마다 제공하는 방법이 다르다.

  +--------+                                           +---------------+
  |        |--(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        +---------------+
  
               Figure 2: Refreshing an Expired Access Token

출처: https://tools.ietf.org/html/rfc6749#section-1.5

정리

• OAuth를 사용자 인증을 위한 방법으로 쓸 수 있지만,
• OAuth의 주요 목적은 허가(Authorization)이다.
• OAuth2.0은 웹 애플리케이션이 아닌 애플리케이션 지원 강화
• OAuth2.0은 암호화가 필요 없음 HTTPS를 사용하고 HMAC을 사용하지 않는다.
• Access Token 갱신 OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할 수 있었다. 트위터의 경우에는 Access Token을 만료시키지 않는다.
• OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다.

출처

[생활코딩] https://opentutorials.org/course/3405

[Naver D2] https://d2.naver.com/helloworld/24942

[HMAC] https://hanee24.github.io/2018/04/22/hmac-authentication/