OAuth2.0 Authorization Code Grant

Jongmyung Choi·2023년 8월 23일

개요

Spring Security를 이용하여 OAuth2.0 의 Authorization Code Grant 방식을 구현하다가 한 여러 삽질을 기록 하기 위해 작성하였다.

Authorization Code Grant 방식

OAuth2.0에 대해 검색해보면 대부분 Authorization Code Grant 방식을 사용하는 걸 알 수 있다.
권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식이고 Spring Security 에서도 이 방식을 사용한다.

검색을 하다보면 이러한 시퀀스 다이어그램을 많이 볼 수 있는데 이 그림 때문에 개발 하는데에 엄청난 삽질을 했다..
(내가 생각한 제대로 된 다이어그램은 뒤에 설명)

발생한 문제

나는 처음에 User를 Front-end로 Client를 Back-end로 이해하고 구현을 했기 때문에 여러 삽질을 하게 됐다.
우선 우리 서비스는 JWT와 OAuth2.0을 사용하여 로그인을 진행하는데 위의 과정을 통해 로그인을 했을 때 발생하는 문제는 다음과 같다.

User(Front-end)가 Client(Back-end)로 요청을 보내지 않아서 JWT 토큰을 발급 해줄 수가 없다.

위 그림 상으로는 User에서 Client로 요청을 보내는게 단 한번이고 로그인 페이지를 요청할 때 이다.
그렇기 때문에 Authorization Server로부터 Client가 승인 코드를 받고 검증을 받고 사용자의 정보를 얻었다 하더라도 User에 이를 알려줄 방법이 없다.
그래서 결론적으로 말하자면 이 다이어그램은 명확하지 않다고 생각한다.

그렇게 생각한 이유

일반적인 웹 서비스는 프론트엔드와 백엔드가 분리되어 있기 때문에 Client는 프론트인지 백엔드인지 아니면 두개를 합친 우리 서비스인지 가 모호하다.
난 이 그림을 이해하기 위해 User와 Client를 여러가지로 해석해봤다.

1. User는 사용자 , Client는 프론트 이다.

-> 이렇게 되면 프론트에서 백엔드(인증서버)를 전혀 거치지 않고 Authorization Server인 카카오 인증서버와 통신하므로 올바르지 않다고 생각했다.

2. User는 사용자 , Client는 백엔드 이다.

-> 사용자가 프론트를 안거치고 백엔드와 통신하는건 말이 안된다.

3. User는 사용자 , Client는 우리 서비스 이다.

-> 이런 상황이면 말이 되긴 하는데.. Oauth를 설명하는데에 있어서 프론트와 백엔드의 통신과정을 시퀀스에 표현을 안하는게 이해하기 어렵게 했다고 생각한다..

이 외에도 User를 프론트, Client를 서버 , Resource Server를 우리 서버의 자원서버 등등 엄청 생각해봤는데 이 그림의 경우는 3번을 표현한 것 같다.

명확한 다이어그램

저 시퀀스가 명확하지 않다고 생각하여 공식문서도 보고 열심히 구글링 한 결과 가장 명확하다고 생각한 다이어그램이다.
여기서 Resource Owner를 프론트엔드, Client를 서버, Authorization Server를 인증서버(Kakao, Google..), Resource Server를 인증서버의 API 라고 생각하면 모든게 맞아 떨어진다.

공식문서에서 설명하는 Authoriaztion Code Flow