[OAuth] PKCE 와 Authorization Code 탈취

저번에 OAuth에서 간단히 요약해보았는데

OAuth 은 비밀번호 없이도 한 어플리케이션에서 특정 어플리케이션의 권한을 받을 수 있는 프로토콜이다.

 

하지만 비밀번호 없이 한다고해도 완벽히 안전하다고는 할 순 없다.

 

OAuth에 흐름을 간단히 짚어보며 알아보려고한다.

 

 

 

우리가 흔히 어느 웹 클라이언트에서 소셜 로그인을 누르면 비밀번호나 아이디를 입력하지 않아도

즉시 내 정보들을 가져옴과 함께 로그인이 된다.

 

로그인을 누르는 순간 해당 리소스 서버의 로그인 창이 나오게 될 것이고

아이디와 비밀번호를 입력하면 해당 서버의 인증서버로 전달이 될 것이다.

 

 

인증을 한 뒤 클라이언트로 인증된 Code를 전달한다.

이때 해당 클라이언트 주소를 Redirect URL이라고 한다.

 

브라우저는 생성된 Code를 클라이언트 서버로 전달한다.

 

그리고 나서 서버 내부에서는 전달 받은 Code를 다시 인증 서버로 가져가 토큰으로 발급 받은 뒤 로그인 인증 처리를 완료하는것이다.

 

이때 드는 의문점이 몇가지가 있었다.

 

그냥 바로 토큰을 받으면안되나??

 

 

바로 토큰을 받을 경우에 다시 서버에서 인증서버로 요청할 일은 없겠지만 그렇게 될 경우 보안적으로 문제가 생긴다.

브라우저가 인증서버로 받아올때는 URL로 노출이되기때문이다.

 

토큰이 노출이 된다면 중간에 토큰을 탈취 당할 가능성이 크기때문에 좋지 않다.

 

그렇게치면 Code 도 브라우저 상에서 노출이 되긴하지만 Code는 일회성이며 유효기간이 짧기때문에 

탈취당한다하더라도 문제가 일어날 가능성이 거의 줄어들게 된다.

 

 

하지만 그래도 완벽하게 안전이 보장된건 아니기때문에 사용하는 이중 안전 장치가 있다.

 

 

 

PKCE

PKCE는 Authorization Code 탈취를 막기 위한 보안 계층이다.

인가 서버에서부터 Code를 받아왔을때 

 

유효기간이 짧아 탈취 당해도 문제가 일어날 가능성이 적긴하지만 이마저도 예방하기 위한 방법이다.

 

인가 요청을 하기 전 클라이언트 서버에서 code_verifier 을 생성한다.

그리고 이 code_verifier를 암호화한 것이 code_challenge 이다.

 

인가요청 하기전 암호화된 challenge를 리소스 서버에 전달하여 저장시킨 후

브라우저에서 아이디와 비밀번호를 입력하여 인가요청을 시도한다.

 

그럼 리소스 서버에서 code를 생성하여 내려줄 것이고 브라우저는 이 code를 담아 나의 클라이언트 서버로 요청한다.

 

 

나의 클라이언트 서버에는 아까 생성해두었던 verifier가 존재한다.

 

code와 verifier를 같이 담아 다시 리소스 서버에 인가요청을 보낸다.

 

그러면 리소스 서버에서는 원본 verifier와 암호화된 challenge를 둘다 전달 받을 수 있고 

둘이 일치하는지 검사를 할 수 있게되는거다.

 

일치하면다면 access_token을 내려주고 일치하지않다면 중간에 탈취당한것으로 판명될 것 이다.

 

 

 

만약 공격자가 첫번째 인가요청에서 받은 code를 탈취하여 리소스 서버로 요청을 보내도 
verifier는 클라이언트 서버만 알기 때문에 이러한 문제를  방지할 수 있다