OAuth Authorization Code Grant 동작 원리 (3/4)

Intro

OAuth2 프로토콜에서는 다양한 클라이언트 환경에 적합한 인증 및 권한의 위임 방법(Grant Type)을 제공하고 그 결과로 클라이언트에게 Access Token을 발급한다.
4개의 권한 위임 방법이 있으며 아래와 같다.

• Authorization Code (권한 부여 승인 코드 방식)
• Implicit (암묵적 승인 방식)
• Client Credentials (클라이언트 자격 증명 승인 방식)
• Resource Owner Password Credentials (자원 소유자 자격증명 승인 방식)

가장 많이 사용하는 Authorization Code (권한 부여 승인 코드 방식)의 동작 원리에 대해 정리하고자 한다.

OAuth인증의 최종 목적은 Access Token을 발급하는 것이다.
한 번의 인증 이후에 실제로 리소스에 접근하기 위해서 필요한 것은 Access Token이기 때문이다.

---

Flow

1.  로그인 요청 (Resource Owner → Client)

Resource Owner가 서비스의 '네이버 로그인' or ‘카카오 로그인’ 버튼을 클릭해 로그인을 요청한다.

 

2. 로그인 요청 (Client → Authorization Server)

• Client는 OAuth 프로세스를 시작하기 위해 사용자의 브라우저를 Authorization Server로 보내야 한다.
• Client는 이때 Authorization Server가 제공하는 Authorization UR에 response_type , client_id , redirect_uri , scope 등의 매개변수를 쿼리 스트링으로 포함하여 보낸다.

https://nid.naver.com/oauth2.0/authorize?response_type=code
&client_id=y8bipAjK2LOF6BcKUBYa     # 어떤 client인지를 id를 통해 Resouce Owner에게 알려주는 부분
&scope=name%20email                 # Resource Owner가 사용하려는 기능, Client가 부여받은 리소스 접근 권한
&redirect_uri=http://localhost:28081/login/oauth2/code/naver     # 응답 콜백

 

3. 로그인페이지 제공 (Authorization Server → Resource Owner)

• Authorization Server는 파라미터로 받은 client_id와 redirect_url이 사전에 등록된 정보와 일치하는지 검증한다.
• 검증이 완료되면 전용 로그인 페이지를 제공한다.

4. ID/PW 제공 (Resource Owner → Authorization Server)

• Scope에 해당되는 권한을 Client에게 부여할 것인지 Resource Owner에게 다시 한번 확인한다.
• ID/PW를 적어서 로그인을 하게 되면, Client가 사용하려는 기능(scope)에 대해 Resource Owner의 승인을 요청한다.

5. Authorization Code 발급 (Authorization Server → Resource Owner)

• Authorization Server는 Authorization code를 Redirect URL을 통해 Resource Owner에게 응답한다.
• Authorization Code란 Client가 Access Token을 획득하기 위해 사용하는 임시 코드이다.
  이 코드는 수명이 매우 짧다. (일반적으로 1~10분)

6. Redirect URI (with, Authorization Code) (Resource Owner → Client)

• Resource Owner는 Authorization Code를 Client에게 다시 보낸다.

7.  Access Token 요청 (Client → Authorization Server)

• Client는 Authorization Server에 Authorization Code, Client ID, Client Secret을 전달하여 Access Token을 요청한다.

8.  Access Token 발급 (Authorization Server → Client)

• Authorization Server는 Client가 전달한 정보들을 비교해서 일치한다면, Access Token을 발급한다. 
• 이제 필요 없어진 Authorization code는 지운다.

9. 로그인 성공 (Client → Resource Owner)

• Access Token을 받은 Client는 Resource Owner에게 최종적으로 로그인이 완료되었다고 응답한다.

10 ~ 13. Access Token으로 리소스 접근

• Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client에 요청한다.
  Client는 위 과정에서 발급받고 저장해 둔 Resource Owner의 Access Token을 사용하여 제한된 리소스에 접근하고, Resource Owner에게 자사의 서비스(Resource)를 제공한다.

---

OAuth 개념, 구성요소, 동작원리, 애플리케이션 등록이 되었기 때문에 Spring Boot 환경에 적용해 보겠다.

Spring Security + OAuth + JWT를 적용할 것이다.

 

놓친 부분이 있다면 이전글을 확인하기 바란다.

• OAuth 개념 파해치기 (1/4)
• OAuth 네이버, 카카오 애플리케이션 등록 (2/4)
• OAuth Authorization Code Grant 동작 원리 (3/4)
• Spring Security + JWT + OAuth2 적용하기 (4/4)

Spring Security, JWT관련된 이전글

• JWT(Json Web Token) 정리
• Spring Security 개념 및 Architecture
• Spring Security + JWT 인증 (1/2) - JWT 구현
• Spring Security + JWT 인증 (2/2) - Spring Security 설정
• Spring Security - FilterSecurityInterceptor 이해 및 Example