[Spring Security] OAuth 2.0 개요

개요

이번 게시글에서는 OAuth 2.0에 대해 간략히 알아보겠습니다.
OAuth 2.0을 이해하기 위해서는 아래의 개념을 알아야 하며 각각의 개념을 간략히 정리하겠습니다.

• 인증과 인가의 차이
• OAuth 2.0 개념
• OAuth 2.0 구성 요소
• OAuth 2.0 Client 
• OAuth 2.0 토큰
• OAuth 2.0 권한부여 유형

 

1. 인증 vs 인가

OAuth 2.0 설명에 앞서 인증(Authentication)과 인가(Authroization)를 확실히 구분한 상태로 읽으시면 좋을 것 같습니다.
 
인증 (Authentication)

• 클라이언트가 요청하는 주체가 자기 자신임을 입증하는 절차
• ex) 로그인

 
인가 (Authorization)

• 인증받은 사용자가 어떤 권한을 갖고 있는지 체크하는 절차
• Role에 따라 부여받은 권한이 다름

 

2. OAuth 2.0 개념

• OAuth는 Open Authorization의 약자
• 풀 네임은 The OAuth 2.0 Authorization Framework (RFC 6749)
• 구글, 페이스북, 네이버, 카카오 등과 같은 기업에서는 당사에서 미리 생성한 리소스를 사용할 수 있도록 api를 제공하는데 해당 기관을 OAuth Provider라고 칭함
• 특정 애플리케이션이 OAuth 2.0 Framework를 적용했고 사용자가 선택한 OAuthProvider로부터 애플리케이션의 접근을 허용하도록 승인했을 경우 해당 앱은 OAuth Provider가 제공하는 데이터를 사용할 수 있음
  • 회원 가입 절차에 주로 사용되므로 사용자의 개인 정보와 같이 민감한 정보를 포함할 수 있기 때문에 애플리케이션과 OAuth Provider 간 미리 약속된 방식으로 데이터를 주고받을 필요가 있는데 이처럼 HTTP 상으로 정보를 안전하게 주고받을 수 있도록 통일한 규약을 OAuth Protocol이라고 함
• 기존 OAuth 방식이 보안에 취약한 문제들이 있었고 이를 개선한 버전을 OAuth 2.0이라고 칭함
• 사용자 입장에서는 OAuth 2.0을 통해 앱을 사용할 때 굳이 개인정보를 기입하며 회원가입 할 필요 없고 앱으로부터 OAuth Provider의 접근 및 권한 부여를 승인하기만 하면 앱에 로그인 가능
• 애플리케이션 입장에서는 개인정보 관리와 같은 책임 소재를 OAuth Provider에게 위임하여 편리

 

2.1 OAuth 2.0 구성 요소

OAuth 2.0 메커니즘은 아래의 네 가지 역할을 담당하는 주체들에 의해 이루어지는 권한 부여 체계입니다.

• Resource Owner
• Resource Server
• Authorization Server
• Client

 
2.1.1 Resource Owner
 

• 리소스 소유자로 해당 리소스로의 접근을 승인할 수 있는 주체
• 보통 end-user라고 칭하고 앱을 사용하는 사용자라고 생각하면 됨
• 앞서 회원 가입 예시에서 개인 정보의 resource owner는 end-user인 자기 자신

 
2.1.2 Resource Server
 

• 타사 애플리케이션에서 접근하는 사용자의 자원이 포함된 서버
• access-token을 수락 및 검증할 수 있어야하며 권한 체계에 따라 요청을 승인할 수 있어야 함

 
2.1.3 Authorization Server
 

• 클라이언트가 사용자 계정에 대한 동의 및 접근을 요청할 때 상호 작용하는 서버로 클라이언트의 권한 부여 요청을 승인 및 거부하는 서버
• 사용자가 클라이언트에게 권한 부여 요청을 승인한 후 access-token을 클라이언트에게 부여하는 역할
• 보통 Resource Server와 Authorization Server는 한 기업에서 담당하며 이 둘이 물리적으로 하나인 경우도 있음

 
2.1.4 Client
 

• 사용자를 대신하여 권한을 부여받아 사용자의 리소스에 접근하려는 애플리케이션
• 사용자를 authrization server로 안내하거나 사용자의 상호 작용 없이 authorization server로부터 직접 권한을 획득할 수 있음

 
2.2 전체적인 flow

 

• Client가 Authorization Server에 권한 부여 요청 (access-token 요청)
• Resource Owner가 권한 부여 요청을 승인할 경우 Authorization Server는 Client에게 access-token 발행
• Client는 발행 받은 access-token과 함께 Resource Server에 리소스 요청
• Resource Server는 Authorization Server 통해 혹은 자체적으로 access-token을 검증한 뒤 Client에게 리소스 반환

 

보다 정확한 예시를 트리플 앱을 기준으로 설명하겠습니다.

 
1. 트리플(Client)에 로그인할 때 OAuth Provider인 구글, 네이버, 페이스북, 카카오톡 혹은 애플 아이디로 로그인할 수 있는 것을 확인할 수 있습니다.
 

 
 
2. 페이스북(Resource Server, Authorization Server)에 권한 부여 요청을 하면 Resource Owner인 저는 로그인 및 권한 제공에 동의를 해야 합니다.
 

페이스북 로그인

 

이미 페이스북 아이디가 있으므로 네이버 권한 동의 페이지

 
3. 2번 과정이 끝나면 access-token이 Client인 트리플에 제공되며 트리플은 이를 기반으로 OAuth Provider에 리소스를 요청해 로그인 처리를 마칩니다.
 

로그인 상태

 

3. OAuth 2.0 Client

앞서 언급한 flow에서 Authorization Server에 Client를 등록할 때 클라이언트 자격 증명인 아이디(client_id)와 비밀번호(client_secret)를 받고 자격 증명에서 공개되는 아이디만 제공됩니다.
클라이언트 종류는 아래와 같이 두 종류인데 종류에 따라 자격 증명에 비밀번호 사용 유무가 갈립니다.

• Confidential Client (기밀 클라이언트)
• Public Client (공개 클라이언트)

 
3.1 Confidential Client
 

• 비밀번호인 client_secret의 기밀성을 유지할 수 있는 클라이언트
• 일반적으로 end_user가 소스 코드에 액세스 할 수 없는 서버단에서 실행되는 응용 프로그램으로 서버 측 언어로 작성
• 해당 유형의 애플리케이션은 대부분 웹 서버에서 실행되기 때문에 일반적으로 '웹 앱'으로 불림

 
3.1.1 Confidential Client 자격 증명 과정 (authorization code flow)

• Client가 권한 부여 요청 (request authorization)
• Authrization Server에서 임시 토큰인 code 반환
• Client가 Authorization Server에 임시 토큰 전달
• Authorization Server가 임시 토큰 검증 후 access-token 반환

 
첫 번째와 두 번째 단계는 보안 수준이 낮은 채널인 front channel에서 이루어지고 세 번째와 네 번째 단계는 보안 수준이 높은 채널인 back channel에서 이루어집니다.
 

 
3.2 Public Client
 

• Chrome 개발자 콘솔이나 디스어셈블러와 같은 디버깅 도구를 사용하여 바이너리/실행 코드에서 기밀 정보를 추출할 수 있는 유형이기 때문에 공개로 간주
• 따라서 비밀번호인 client_secre의 기밀성을 유지할 수 없기 때문에 이러한 앱에서는 client_secret이 자격 증명 과정에 사용되지 않음
• 브라우저에서 실행되는 javascript 애플리케이션, 안드로이드 혹은 IOS 모바일 앱, 데스크톱에서 실행되는 기본 앱 뿐만 아니라 IOT/임베디드 장치에서 실행되는 애플리케이션 등이 있음
  • 서버가 아닌 리소스 소유자가 사용하는 장치에서 실행되는 모든 클라이언트는 Public Client로 간주

 
3.2.1 Public Client 자격 증명 과정 (implicit flow)

• Client가 Authorization Server에 권한 요청
• Authorization Server가 바로 access-token 반환

 
위 과정은 모두 보안 수준이 낮은 채널인 front channel에서 이루어지며 이 때문에 implicit flow는 현재 deprecated 처리되었습니다.
대신 Public Client는 후술 할 Authorization Code with PKCE 기법을 사용합니다.

 

4. OAuth 2.0 토큰

OAuth 2.0 토큰은 아래와 같이 네 종류가 있습니다.

• Access Token
• Refresh Token
• Authorization Code
• ID Token

 
해당 게시물에서는 ID Token을 제외한 나머지 세 가지 토큰에 대해 정리하겠습니다.

 
4.1 Access Token
 

• Client에서 Resource Owner의 보호된 리소스에 접근하기 위해 사용하는 일종의 자격 증명으로서 역할
• Resource Owner가 클라이언트에게 부여한 권한 부여의 표현
• 일반적으로 JWT 형식을 취하며 액세스 기간, 범위 및 서버에 필요한 기타 정보를 지니고 있음

 
4.2 Refresh Token
 

• Access Token이 만료된 후 새 액세스 토큰을 얻기 위해 Client에서 사용하는 자격 증명
• Access Token이 만료되는 경우 Client는 Authorization Server로 인증하고 Refresh Token 전달
• Authorization Server는 Refresh Token의 유효성을 검사하고 새 Access Token 발급
• Refresh Token은 Access Token과 달리 Authorization Server 토큰 앤드포인트에만 보내지고 Resource Server에는 보내지 않는다
  • Authorization Server로부터 새로운 Access Token 받는 용도이기 때문

 
4.3 Authorization Code
 

• 앞서 간단히 언급한 authorization code flow에서 사용되며 해당 코드는 Client가 access-token과 교환할 임시 토큰

 

4.4 ID Token

 

• OpenID Connect 사용 시 인증에 대한 정보는 ID Token이라고 하는 JSON 웹 토큰(JWT)로 반환
• 정리하자면 OpenID Conenct는 클라이언트가 사용자 ID를 확인할 수 있게 하는 보안 토큰인 ID Token 제공
• Access Token의 경우 인증 보장이 아닌 수단이지만 ID Token의 경우 인증되었다는 것을 보장
  • ID Token은 개인 키로 발급자가 서명하는 것으로서 토큰의 출처를 보장하고 변조되지 않았음을 보장
• ID Token은 API 요청에 사용해서는 안되며 사용자의 신원 확인을 위해 사용
  • 반면 Access Token은 인증을 위해 사용해서는 안되며 리소스에 접근하기 위해 사용

 

5. OAuth 2.0 권한부여 유형 (Authorization Grant Type)

권한 부여란 Client가 Resource Owner 대신해서 Resource Owner의 승인 하에 Authorization Server로부터 권한을 부여받는 것을 의미합니다.
OAuth 2.0 메커니즘은 아래와 같이 6가지가 있으며 두 가지는 Deprecated 처리되었습니다.

• Authorization Code Grant Type
• Implicit Grant Type (Deprecated)
• Resource Owner Password Credentials Grant Type (Deprecated)
• Client Credentials Grant Type
• Refresh Token Grant Type
• PKCE-enhanced Authorization Code Grant Type

 

각 메커니즘을 설명하기 전 자격 증명 과정에서 전달하는 매개 변수 용어를 간단히 정리하겠습니다.

• client_id: Authorization Server에 등록된 Client에 대해 생성된 고유 Key
• client_secret: Authorization Server에 등록된 특정 클라이언트의 client_id에 대해 생성된 비밀 값
• response_type: 애플리케이션이 권한 부여 흐름을 시작하고 있음을 Authorization Server에 알리는 역할
• grant_type: 권한 부여 타입 지정 (사용할 OAuth 2.0 매커니즘을 명시)
• redirect_uri: 사용자가 응용 프로그램을 성공적으로 승인하면 Authorization Server가 사용자를 다시 응용 프로그램으로 redirect
  • 토큰 요청의 redirect_uri와 인증 코드를 생성할 때 사용된 redirect_uri는 정확히 일치해야 함
• scope: 앱이 사용자 데이터에 접근하는 것을 제한하기 위해 사용
• state: CSRF 공격을 방지하는 데 사용되는 값

 

또한 각 메커니즘은 Keycloak 19.0.1 버전을 통해 실습하였고 흐름을 이해하는 것이 핵심이기 때문에 Keycloak 설정 방법은 생략하도록 하겠습니다.

 
5.1 Authrization Code Grant Type
 

앞서 Confidential Client 자격 증명 과정에서 설명한 메서드이며 자주 사용되는 안전한 메서드이기 때문에 복습하는 차원에서 전체적인 flow를 다시 작성하겠습니다.

• Resource Owner가 애플리케이션을 승인하면 Authorization SErver는 Redirect URI로 임시 코드 담아서 애플리케이션으로 다시 redirect
• 애플리케이션은 해당 임시 코드를 Authorization Server로 전달하고 access-token으로 교환
• 애플리케이션이 access-token을 요청할 때 해당 요청을 client_secret으로 인증할 수 있으므로 Man in the Middle 공격을 당해 access-token을 탈취당해도 공격자가 client_secret을 모르면 무용지물이기 때문에 보안 위험이 줄어듦
• access-token이 사용자 또는 브라우저에 표시되지 않고 애플리케이션에 다시 전달하는 가장 안전한 방법이므로 토큰이 다른 사람에게 누출될 위험이 줄어듦

 

https://docs.vmware.com/en/Single-Sign-On-for-VMware-Tanzu-Application-Service/1.14/sso/GUID-grant-types.html

 

임시 코드 요청 시 필요한 매개변수

• response_type=code (필수)
• client_id (필수)
• redirect_uri (선택사항)
• scope (선택사항)
• state (선택사항)

 

access-token 교환 요청 시 매개변수

• grant_type=authorization_code (필수)
• code (필수)
• redirect_uri (임시 코드 요청 시 redirect_uri 전달했으면 필수)
• client_id (필수)
• client_secret (필수)

 

Postman 예시
 
1. 임시 코드 요청
 

임시 코드 요청

 
redirect 주소: http://localhost:8081/?session_state=106bd029-6325-4ffa-8653-28fca8690487&code=400bae83-8a80-4320-887e-d14f10b6fab5.106bd029-6325-4ffa-8653-28fca8690487.bee09db4-926e-4f19-a20b-e6acd32132ed
 
2. access-token 교환 요청
 

access-token 교환 요청

 
access_token과 refresh_token을 반환하는 것을 확인할 수 있습니다.

 
5.2 Implicit Grant Type (Deprecated)
 

임시 code를 요청하는 과정 없이 바로 access-token을 요청하는 메서드로 보안에 취약해 deprecated 처리된 메서드입니다.
전체 flow는 아래와 같습니다.

• 클라이언트에서 javascript 및 html 소스 코드를 다운로드한 후 브라우저는 서비스에 직접 API 요청
• 코드 교환 단계를 건너뛰고 대신 access-token이 쿼리 문자열 조각으로 클라이언트에 즉시 반환
• 해당 유형은 모두 front channel에서 수행되므로 refresh token을 사용하지 못하기 때문에 refresh token을 반환받지 않음

 

https://docs.vmware.com/en/Single-Sign-On-for-VMware-Tanzu-Application-Service/1.14/sso/GUID-grant-types.html

 

요청 시 필요한 매개변수

• respone_type=token 혹은 id_token (필수)
• client_id (필수)
• redirect_uri (필수)
• scope (선택 사항)
• state (선택 사항)

 

Postman 예시
 

 
redirect 주소: http://localhost:8081/#session_state=106bd029-6325-4ffa-8653-28fca8690487&access_token=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI0RDhqTUNVU0VVLVJKNTBXZGRHZ19CWS16UVNodzV1ZlRSd0FyUV9ua25jIn0.eyJleHAiOjE3MDMxNjY4NzAsImlhdCI6MTcwMzE2NTk3MCwiYXV0aF90aW1lIjoxNzAzMTY1NTc3LCJqdGkiOiI4ZjQ4YTk0Zi03ZTRiLTQ3NjgtODc2OS02NmIwOTE5ZjM5NmEiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvcmVhbG1zL29hdXRoMiIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiJjMWY1M2YxNy0zOWIwLTRjMTUtYTFiYS0wOTRjMDA2YmZhYjkiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJvYXV0aDItY2xpZW50LWFwcCIsInNlc3Npb25fc3RhdGUiOiIxMDZiZDAyOS02MzI1LTRmZmEtODY1My0yOGZjYTg2OTA0ODciLCJhY3IiOiIwIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLW9hdXRoMiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoicHJvZmlsZSBlbWFpbCIsInNpZCI6IjEwNmJkMDI5LTYzMjUtNGZmYS04NjUzLTI4ZmNhODY5MDQ4NyIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwibmFtZSI6ImphaW1lIG1pbiIsInByZWZlcnJlZF91c2VybmFtZSI6InVzZXIiLCJnaXZlbl9uYW1lIjoiamFpbWUiLCJmYW1pbHlfbmFtZSI6Im1pbiIsImVtYWlsIjoidXNlckBrZXljbG9hay5jb20ifQ.Ou-79NSZ3YMOfsIUIc__90obCV04FyYiIJFYcVgSxv2Mo0gwL-5ytSPqqooXP-GbUvjD08g26H9R_7WFfvrddsDu4xdHOlydRsQrS2If8_WIZxamCD6xmws8VGDGNvwjXLFOow4DRWvxue8PQ8hf8vp4VEUXKdJRYyCfjfGaFBqB0ruWstSS4gPltpkkmd140dDlf5_ftEWWNTkO4rsTM-XHFopBaICHxIZ4AJIlFk_tgHGXupAl6xZJI7c3tWe5PzlgWmSwFaDtmjcC-J6Xto77uTmW4QUNKXA2utE0wVPswJXABUj5D4CPWSRxw3l1SDHbgrWFs08uON9FacInHQ&token_type=Bearer&expires_in=900
 
Authorization Code Grant Type과 달리 임시 코드 과정을 생략하고 access-token을 바로 반환하는 것을 확인할 수 있습니다.

 
5.3 Resource Owner Password Credentials Grant Type (Deprecated)
 

애플리케이션이 client_id와 client_secret을 함께 전달하여 access-token으로 교환할 때 사용되는 메서드입니다.
client_secret을 함께 전달하기 때문에 타사 애플리케이션이 해당 권한을 사용하도록 허용해서는 안되고 고도의 신뢰할 자사 애플리케이션에서만 사용해야 합니다.
해당 메서드 또한 보안 취약점이 존재하므로 deprecated 처리되었습니다.

 

https://docs.vmware.com/en/Single-Sign-On-for-VMware-Tanzu-Application-Service/1.14/sso/GUID-grant-types.html

 

요청 시 필요한 매개변수

• grant_type=password (필수)
• username (필수)
• password (필수)
• client_id (필수)
• client_secret (필수)
• scope (선택 사항)

 

postman 예시
 

 
access_token과 refresh_token을 반환하는 것을 확인할 수 있습니다.

 
5.4 Client Credentials Grant Type
 

애플리케이션이 Resource Owner인 동시에 Client 역할을 하는 경우 사용되는 메서드이며 서버 대 서버 통신에 사용됩니다.
즉, Resource Owner에게 권한을 위임받아 리소스를 접근하는 것이 아니라 자기 자신이 애플리케이션을 사용할 목적으로 사용하는 경우 사용되는 메서드입니다.
client_id와 client_secret을 통해 access-token을 바로 발급받을 수 있기 때문에 refresh token을 제공하지 않고 client 정보를 기반으로 하기 때문에 유저 정보를 제공하지 않습니다.

 

"Implicit Grant Type이랑 비슷해 보이는데 왜 해당 메서드는 보안 취약점에 대한 언급이 없을까?"라고 물어보신다면 글을 잘 읽고 계셨다는 반증입니다.

• Implicit Grant Type은 보안이 취약한 front channel에서 이루어지는 반면
• Client Credentials Grant Type의 경우 보안이 강화된 back channel 즉, 서버 대 서버 간의 통신에서 사용됩니다.

 

https://docs.vmware.com/en/Single-Sign-On-for-VMware-Tanzu-Application-Service/1.14/sso/GUID-grant-types.html

 

요청 시 필요한 매개변수

• grant_type=client_credentials (필수)
• client_id (필수)
• client_secret (필수)
• scope (선택 사항)

 

postman 예시
 

 
앞서 언급했듯이 해당 메서드는 user 정보를 반환하지 않습니다.
따라서 access-token을 사용해 user info api를 호출하더라도 다른 메서드와 달리 유저 정보가 생략된 정보가 반환되는 것을 확인할 수 있습니다.
 

user 정보가 생략된 반환 값

 

Authrization Code Grant Type로 요청했을 때는 user 정보가 존재하는 것을 확인 가능

 
5.5 Refresh Token Grant Type
 

access-token이 발급될 때 함께 제공되는 토큰으로서 액세스 토큰이 만료되더라도 함께 발급받은 리프레쉬 토큰을 통해 인증 과정을 처음부터 반복하지 않더라도 access-token을 재발급 받을 수 있습니다.
당연하게도 refresh-token을 반환하지 않는 Client Credentials Grant Type과 Implicit Grant Type 메서드 사용 시 해당 메서드를 사용할 수 없습니다.
한 번 사용된 refresh-token은 재사용하거나 폐기할 수 있지만 보안을 고려했을 때 폐기하고 새로 생성하는 것을 권장합니다.

 

https://is.docs.wso2.com/en/5.9.0/learn/refresh-token-grant/

 

요청 시 필요한 매개변수

• grant_type=refresh_token (필수)
• refresh_token (필수)
• client_id (필수)
• client_secret (필수)

 

postman 예시
 

 
앞서 Resource Owner Password Credentials Grant Type에서 발급받은 refresh-token으로 새로운 access-token을 받는 것을 확인할 수 있었습니다.

 
5.6 PKCE-enhanced Authorization Code Grant Type

 
Authorization Code Grant Type의 확장 버전으로 권한 부여 코드 요청 시 Code Verifier와 Code Challenge를 추가하여 만약 Authorization Code Grant Flow에서 Authorization Code가 탈취당했을 때 access-token을 발급하지 못하도록 차단합니다.
PKCE(Proof Key for Code Exchange)는 원래 모바일 앱에서 Authorization Code Grant Flow를 보호하도록 설계되었으며 추후 단일 페이지 앱에서도 사용하도록 권장됐으며 모든 유형의 OAuth2 클라이언트 심지어 클라이언트 암호를 사용하는 웹 서버에서 실행되는 앱에도 유용합니다.

 

정리하자면 아래의 유스 케이스에 사용됩니다.

• 모바일 앱
• SPA 앱
• 모든 유형의 OAuth2 클라이언트
• 클라이언트 암호를 사용하는 웹 서버

 

Code Verifier

• 권한 부여 코드 요청 전 앱이 원래 생성한 PKCE 요청에 대한 코드 검증기
• 48~128 글자수를 가진 무작위 문자열
• A~Z, a~z, 0~9, -._~의 ASCII 문자열로 구성

 

Code Challenge

• 선택한 해시 알고리즘으로 Code Verifier를 해싱한 후 Base64 인코딩을 한 값

 

Code Challenge Method

• plain: Code Verifier 평문 그대로 사용
• S256: Code Verifier 해시 알고리즘 사용하도록 설정

 

전체적인 flow

• Client는 code verifier를 생성하고 code challenge method를 사용하여 code verifier를 기반으로 code challenge 생성
• Client가 Authorization Server에 권한 부여 요청
• Authorization Server가 권한 부여 요청에 대한 OAuth2 요청 유효성 검증 수행
• Authorization Server가 code challenge 및 code challenge method의 존재 확인
• Authorization Server가 권한 코드에 대해 code challenge 및 code challenge method 저장
• Authorization Server가 권한 코드 반환
• Client가 추가 code verifier를 포함해 권한 코드를 Authorization Server에 전달해 access-token 요청
• Authorization Server가 제공된 code verifier 및 저장된 code challenge method를 사용하여 고유 code challenge 생성
• Authorization Server가 생성된 code challenge를 초기 요청에서 제공된 code challenge 값과 비교
• 두 값이 일치할 경우 access-token 반환, 불일치할 경우 요청 거부

 

https://blog.postman.com/pkce-oauth-how-to/

 

Postman 예시
 
code verifier와 code challenge 생성은 에서 https://tonyxu-io.github.io/pkce-generator/에서 진행 가능합니다.

Online PKCE Generator Tool

 
* code verifier를 기반으로 code challenge를 생성하므로 code verifier를 먼저 생성한 뒤 code challenge를 생성해야 합니다!
 
1. 권한 코드 요청
 

 
반환받은 권한 토큰: 6c7f2a07-0c15-479c-8a49-ea50f84ce135.106bd029-6325-4ffa-8653-28fca8690487.bee09db4-926e-4f19-a20b-e6acd32132ed
 
2. access-token 요청
 

access-token 요청

 

참고

인프런 - 스프링 시큐리티 OAuth2 (정수원 강사님)
 
https://letsmakemyselfprogrammer.tistory.com/103

[RFC 표준] OAuth 2.0를 쉽고 정확하게 알아보자! (기초 개념 및 용어 정리)