상황별 OAuth grant_type의 사용

OAuth 2.0 grant_type

저번 포스팅에서 OAuth에서는 다양한 인증 플로우가 있다는 것을 이야기 하였는데요, 이번에는 어떤 플로우를 사용해야하는지에 대해 알아보도록 하겠습니다. OAuth가 왜 이해하기 어려운지와 다양한 인증 플로우는 이전 글을 참고하세요.
2022.05.23 - [개발자] - OAuth 2.0이 왜 어려울까?

OAuth 2.0이 왜 어려울까?

우선은 OAuth에서 사용하는 용어부터 정리하고 시스템에 필요한 플로우들을 알아보도록 하겠습니다.

• 리소스 오우너 (Resource Owner): 보호된 리소스에 접근을 허가하는 엔티티로, 주로 최종 사용자 입니다.
• 클라이언트 (Client): 리소스 오우너를 대신하여 보호된 리소스에 접근을 요청하는 어플리케이션입니다.
• 리소스 서버 (Resource Server): 보호된 리소스 정보를 가지고 있는 서버입니다. 여러분이 접근하려는 API이지요.
• 인증 서버 (Authorization Server): 리소스 오우너를 인증하고 그에 맞는 리소스 접근 범위를 획득한 후 억세스 토큰을 발급하는 서버입니다.
• 유저 에이전트 (User Agent): 리소스 오우너에 의해 클라이언트와 상호작용하기 위해 사용되는 에이전트. 브라우저나 모바일 어플리케이션입니다.

이제, 어떤 OAuth 플로우를 사용해야하는지 대표적인 인증방식들을 예제로 알아보겠습니다.

인증 방식	적용 케이스
Client Credential Flow	리소스에 접근하는 주체가 머신(서버)일 경우 사용합니다. 이 경우 클라이언트가 리소스 오우너가 되는 형태이며, 사용자의 승인이 필요없는 경우입니다. 예를 들어 환율 API에서 환율 정보를 가져오는 경우 서버와 서버간의 통신이므로 client credential flow를 사용할 수 있습니다. 인증 서버에서 Client ID와 Client Secret를 발급하여 클라이언트 서버에서 API에 접근하게 할 수 있습니다.
Authorization Code Flow	클라이언트가 웹 어플리케이션일 경우 사용합니다. 사용자 입장에서 많이 볼 수 있는 형태로, Facebook이나 카카오 로그인 후 어플리케이션에게 나의 리소스(이름, 나이, 이메일, 성별 등)에 대한 접근을 사용자가 승인해주는 형태입니다. 어플리케이션이 사용자 승인을 획득하면, 리소스 서버에서 사용자 정보를 획득하여 저장할 수 있습니다.
Resource Owner Password Flow	클라이언트가 100% 신뢰할 수 있는 경우 사용할 수 있습니다만, 저는 한 번도 이것이 적용된 어플리케이션을 본 적은 없습니다. 사용자가 어플리케이션에서 유저명과 비밀번호를 입력하면 리소스 서버에 이 Credential을 보내 인증을 받는 형태인테, Authorization Code Flow가 절대 불가능할 경우에만 권고됩니다.
Implicit Flow with Form Post	싱글 페이지 어플리케이션(SPA)의 경우 사용할 수 있는 인증 플로우 입니다. SPA에서 사용할 수 있는 Flow 옵션은 두가지가 있는데 하나는 Authorization Code Flow with PKCE이고 다른 하나가 Implicit Flow입니다. 보통 Authorization Code Flow with PKCE를 권고하는데, 이는 억세스 토큰이 클라이언트 사이드에 노출되지 않고 리프레시 토큰을 리턴할 수 있기 때문입니다. 만약 SPA가 억세스 토큰이 필요하지 않을 경우 Implicit Flow with Form Post를 사용하면 되지만, 대부분 Authorization Code Flow with PKCE를 사용한다고 보시면 됩니다.
Authorization Code Flow with PKCE	SPA나 네이티브/모바일 앱일 경우 사용합니다. 모바일 어플리케이션에서 카카오 인증이 대표적인 예입니다.

이번 포스팅에서는 어떤 Flow를 사용해야 하는지 알아보았고, 실제 각 플로우가 어떤 방식으로 작동하는지 시퀀스 다이어그램과 함께 다음 포스팅에서 알아보겠습니다.