Springboot - OAuth 2.0(Open Authorization) 인증 방식의 이해

0. OAuth 2.0 인증 방식에 이해

사용자가 자신의 계정 정보를 직접 공유하지 않아도 서드 파티 애플리케이션들이 제한된 접근을 할 수 있게 해줍니다.

 

 

구분 설명

인증(Authentication)	ID와 비밀번호로 사용자 신원을 확인 각 서비스에 사용자가 카카오계정으로 로그인할 수 있는 기능 지원서비스에서 각 사용자를 식별할 수 있는 고유한 회원번호 제공참고: https://developers.kakao.com/docs/latest/ko/kakaologin/common#oidc 지원, 로그인 세션 대신 사용 가능한 ID 토큰 제공 가능
인가(Authorization)	사용자 개인정보와 같은 자원(Resource)에 대한 접근 권한 획득https://developers.kakao.com/docs/latest/ko/kakaologin/common#authorization를 바탕으로 사용자 정보나 기능에 대한 접근 권한을 https://developers.kakao.com/docs/latest/ko/kakaologin/common#token 형태로 서비스에 부여

 

 

1. Authorization Code Grant (인증 코드 부여)

• 개념:
  • 이 방식은 세 번째 자(Third-party) 애플리케이션에 액세스 토큰을 직접 전달하지 않습니다.
  • 대신 인증 코드가 클라이언트로 전달되며, 이 코드를 사용하여 액세스 토큰을 얻을 수 있습니다.
• 사용처:
  • 웹 애플리케이션이나 모바일 애플리케이션과 같이 클라이언트 비밀(client secret)을 안전하게 보관할 수 있는 환경에서 사용됩니다.
• 흐름:
  1. 유저가 클라이언트를 통해 리소스 소유자로 로그인합니다.
  2. 인증 서버는 인증 코드를 클라이언트에게 반환합니다.
  3. 클라이언트는 인증 코드와 클라이언트 비밀을 인증 서버에게 전송하여 액세스 토큰을 얻습니다.

 

2. Implicit Grant (암시적 부여)

• 개념:
  • 이 방식은 클라이언트에게 인증 코드를 제공하는 대신 바로 액세스 토큰을 전달합니다.
• 사용처:
  • 주로 JavaScript를 사용한 클라이언트 사이드 애플리케이션에서 사용됩니다.
  • 이 방식은 클라이언트 비밀을 저장할 수 없는 상황에서 사용됩니다.
• 흐름:
  1. 유저가 클라이언트를 통해 리소스 소유자로 로그인합니다.
  2. 인증 서버는 액세스 토큰을 바로 클라이언트에게 반환합니다.

 

3. Resource Owner Password Credentials Grant (리소스 소유자 암호 자격증명 부여)

• 개념:
  • 이 방식은 사용자의 아이디와 비밀번호를 직접 요구합니다.
  • 사용자의 자격 증명을 사용하여 액세스 토큰을 얻을 수 있습니다.
• 사용처:
  • 이 방식은 클라이언트가 사용자의 자격증명을 안전하게 처리할 수 있을 때, 특히 사용자와 클라이언트 사이에 높은 신뢰가 있을 때 사용됩니다.
• 흐름:
  1. 유저가 아이디와 비밀번호를 클라이언트에게 제공합니다.
  2. 클라이언트는 이 자격 증명을 사용하여 인증 서버에 액세스 토큰을 요청합니다.

 

4. Client Credentials Grant (클라이언트 자격증명 부여)

• 개념:
  • 이 방식은 클라이언트 자격증명을 사용하여 액세스 토큰을 얻는 방법입니다.
• 사용처:
  • 이 방식은 클라이언트 자체의 리소스에 접근할 때 주로 사용됩니다.
• 흐름:
  1. 클라이언트는 자신의 ID와 비밀번호를 사용하여 인증 서버에 액세스 토큰을 요청합니다.

각 인증 방식은 상황과 요구 사항에 따라 다르게 적용될 수 있으며, 각 방식의 보안 리스크와 트레이드 오프를 고려하여 적절한 방식을 선택해야 합니다.

 

 

문서

https://datatracker.ietf.org/doc/html/rfc6749

RFC 6749: The OAuth 2.0 Authorization Framework

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

   그림 2에 설명된 흐름에는 다음 단계가 포함됩니다.
   (A) 클라이언트는
        권한 부여 서버로 인증하고 권한 부여를 제시하여 액세스 토큰을 요청합니다. 
   (B) 권한 부여 서버는 클라이언트를 인증하고
        권한 부여를 검증하고 유효한 경우 액세스 토큰
        과 새로 고침 토큰을 발급합니다. 
   (C) 클라이언트는
        액세스 토큰을 제시하여 리소스 서버에 보호된 리소스를 요청합니다. 
   (D) 리소스 서버는 액세스 토큰의 유효성을 검사하고 유효한 경우
        요청을 처리합니다. 
   (E) 액세스 토큰이 만료될 때까지 (C) 및 (D) 단계를 반복합니다. 클라이언트
        가 액세스 토큰이 만료되었음을 알면 단계 (G)로 건너뜁니다.