Proof Key for Code Exchange(PKCE)

  프로젝트에서 OAuth 로그인을 구현하기 위해 OAuth 플로우를 찾아보던 중 여러 플로우가 존재하는 것을 알게 되었다. 그 중, 이번 프로젝트에 사용할 방식인 PKCE를 정리해보려 한다. PKCE는 클라이언트가 네이티브 앱이나 SPA일때 추천되는 방식이다.

  퍼블릭 클라이언트가 엑세스 토큰을 요청했을 때, 인증 절차만으로는 해결할 수 없는 보안 문제에 노출된다. 이는 네이티브앱과 SPA가 가진 특징 때문이다.

  네이티브 앱들은 다음과 같은 문제를 가지고 있다.

    1. client secret을 안전하게 저장할 수 없다. 앱을 디컴파일링 하면 클라이언트 암호가 노출된다.

    2. Custom URL scheme을 통해 리다이렉트를 캡쳐해 악의적 애플리케이션이 인증 서버에서 인증 코드를 받을 수 있다. 

  SPA는 다음과 같은 문제를 가지고 있다.

    1. 모든 코드를 브라우저에서 볼 수 있기 때문에 client secret을 안전히 저장할 수 없다.

  이런 문제들을 해결하기 위해 OAuth 2.0 RFC 7636에 정의된 PKCE를 사용하는 것을 추천한다.

  PKCE는 기존 Authorization code flow를 강화한 버전으로 정적 클라이언트 암호를 대신해 동적으로 생성한 문자열을 사용한다.

용어 정의

  PCKE 플로우를 설명하기 전에 PCKE에서 사용하는 용어 부터 정의하고 가자.

  code verifier: 앱에 의해 생성된 랜덤한 문자열이다. 동적으로 생성된 이 문자열은 첫 인증 요청과 마지막 엑세스 토큰 요청을 연결시킨다.

  code challenge: code verifier에서 도출된 것이다. 이는 code verifier를 평문(plain)으로 사용하거나 S256를 이용해 생성해야 한다. 이 중 되도록이면 S256을 사용해야 하며 client verifier를 SHA256으로 암호화하고 base64로 인코딩해서 code challenge를 만들 수 있다. code challenge는 서버에서 복호화되고 동일 클라이언트에서 전송한 요청인지를 확인하는데 사용된다.

  code challenge method: 어떤 방법을 사용해 code verifier를 변환했는지를 서버에게 알린다. 비워놓으면 plain으로 인식한다.

PKCE 플로우

  PKCE는 다음과 같은 플로우를 가진다

(OAuth tenant가 access token을 응답할 때 ID token도 같이 응답된다)

SPA에서 PKCE를 사용하는 예시: 링크

Standard Authorization Code Flow

  PKCE의 장점을 더 잘 이해하기 위해 기존의 authorization code flow를 보자. 이는 SSR을 상정하고 나온 플로우이기 때문에 정적인 client sercret을 그대로 전송하게 된다. 해당 플로우는 OAuth 2.0 RFC 6749, section 4.1에 정의되 있다.

출처:

Authorization Code Flow with Proof Key for Code Exchange(PKCE)

PCKE: What and Why?

Authorization Code Flow