Oauth2 Grant Type 권한부여 유형

Oauth2 가 제공하는 권한부여 유형에 대해서 알아보자.

 

권한부여란 무엇일까?

권한부여란 클라이언트(앱, 웹, 등등..)가 사용자(리소스 오너)를 대신해서 사용자의 승인하에 인가서버로부터 권한을 부여받는 것을 의미한다.

OAuth 2.0 메커니즘은 아래와 같은 권한 부여 유형들을 지원하고 있으며 일부는 Depreacted 되었다.

 

 

권한부여 유형

 

1. Authorization Code Grant Type

• 권한 코드 부여 타입, 서버 사이드 어플리케이션(웹 어플리케이션), 보안에 가장 안전한 유형
• 백엔드 서버를 통해서 인가서버와 통신이 이루어 진다(code 교환 및 accessToken 발급)

 

로그인 시에 인가서버의 로그인창을 이용하여 사용자의 ID, PASSWORD 를 입력받는다.

로그인이 성공하게 되면 설정한 redirectUri(백엔드 서버)로 code를 포함한 데이터를 전달한다.

이후에 백엔드 서버에서 code를 포함한 데이터를 인가서버의 /token API 를 통해서 해당 사용자의 AccessToken을 발급 받는다.

 

 

2. Implicit Grant Type (Deprecated)

• 암시적 부여 타입, 공개 클라이언트 어플리케이션 (SPA 기반 자바스크립트 앱, 모바일 앱), 보안에 취약

 

로그인 시에 인가서버의 로그인창을 이용하여 사용자의 ID, PASSWORD 를 입력받는다.

로그인이 성공하게 되면 어플리케이션 (SPA 기반 자바스크립트 앱, 모바일 앱) 으로 바로 AccessToken이 전달된다.

백엔드 서버를 통하지 않고 공개클라이언트로 토큰이 바로 전달되기 때문에 보안상 문제가 발생할 수 있다.

 

 

3. Resource Owner Password Credentials Grant Type (Deprecated)

• 리소스 사용자 비밀번호 자격증명 부여 타입, 서버 어플리케이션, 보안에 취약
• 해당 방식은 서버를 신뢰할 수 있을때만 사용해야 한다.

 

자체구현한 어플리케이션의 로그인창을 이용하여 로그인을 하게 된다.

클라이언트가 ID, PASSWORD를 입력하면 인가서버의 /token API를 통해서 인증을 받고, AccessToken을 발급 받는다.

이 과정에서 해당 어플리케이션이 사용자의 ID, PASSWORD를 알수있기 때문에 신뢰하는 어플리케이션에서만 사용해야 한다.

 

 

4. Client Credentials Grant Type

• 클라이언트 자격 증명 권한 부여 타입 , UI or 화면이 없는 서버 어플리케이션

 

해당 방식은 사용자가 클라이언트가 아닌, 백엔드 서버가 클라이언트가 되는 방식이다. Server To Server 에서 요청한 백엔드 서버의 인가정보를 확인하는 용도로 사용한다.

 

 

5. Refresh Token Grant Type

• 새로고침 토큰 부여 타입, Authorization Code, Resource Owner Password Type 에서 지원

 

Authorization Code, Resource Owner Password Type 사용하게 되면 access_token, refresh_token을 발급 받게 되는데

기본적으로 access_token은 유효기간이 짧다. 그렇기 때문에 토큰이 만료되게 되면 재발급을 받아야하는데, Authorization Code, Resource Owner Password Type 방식을 통해서 토큰을 재발급 받기에는 클라이언트가 다시 로그인해야 하거나 복잡하기 때문에 refresh_token을 이용하여 access_token을 재발급 받는 방식이다.

 

 

6. PKCE-enhanced Authorization Code Grant Type

• PKCE 권한 코드 부여 타입 , 서버 사이드 어플리케이션, 공개 클라이언트 어플리케이션

 

Authorization Code Grant Type 에서 보안이 더 강화된 방식이다.

code_challenge, code_challenge_method, code_verifier 를 사용하여 더 강화된 통신을 제공한다.

 

 

 

권한 부여 흐름 선택 기준

 

front Channel(공개 클라이언트, 누구나 접속 가능한 채널)

보안에 강력한 권한부여 흐름을 선택해야한다.

Authorization Code with PKCE 가 가장 적합 하며,

PKCE 를 브라우저가 지원하지 않는경우 Implicit Flow를 사용한다.(해당 타입은 AccessToken을 탈취당할수 있기 때문에 공개 클라이언트 상황에서는 사용하지 않는것이 좋다)

 

back Channel(비공개 클라이언트, 회사내부 or 클라우드 내부에 서버가 존재하여 누구나 접속 불가능한 채널)

제공하려는 클라이언트가 사용자를 대상으로하는것이 아닌경우(데몬, 배치서비스 등...) Client Credentials Flow를 선택한다.

제공하려는 클라이언트가 사용자가 로그인하여 사용자에게 어떤 서비스를 제공해야하는 경우 Authorization Code Flow, Resource Owner Flow를 선택한다.

해당 서비스가 신뢰성이 매우 높은경우(해당 서비스에 클라이언트 계정, 비밀번호를 노출해도 상관없는 경우, 회사 내부 서비스 등..) Resource Owner Flow를 사용

아닌경우 Authorization Code Flow

 

그냥 Authorization Code Flow 사용하는 것을 추천한다.

 

 

References 및 사진 출처

정수원 스프링 시큐리티 OAuth2