728x90
반응형
요약
인증 방법 중, Authorization Code Grant flow가 있음. 이걸 구현하는 표준은 OAuth2.0이 있으나, 최근 OAuth2.1로 업데이트 되면서 PKCE([픽시]) 라는 개념도 도입함
기존 OAuth2.0 플로우
- 클라이언트 -> 리소스 서버에 GET 요청 -> 사용자가 ID, PW 입력 -> 서버가 Authorization Code를 클라이언트에 내려줌
- 클라이언트는 Authorization Code와 함께 ClientID, ClientPassword 등을 서버에 POST 요청하여 Access Token을 얻음.
- 얻어온 Access Token으로부터 사용자에 관련된 역할, profile 정보 등을 확인
기존 문제점
- 서버에서 Authorization Code를 클라이언트에 내려줄 때, 공격자가 이를 감청하면 서버에 Authorization Code를 전달하여 Access Token을 얻어서 해킹 가능(GET 방식, SPA | Native App의 경우)
PKCE OAuth2.1 방식
- 클라이언트가 단방향 hashing을 이용해서 code_verifier - code_challenge 값을 만들어서 서버에 GET 요청 시 파라미터로 code_challenge 값을 전달
- code-verifier는 클라이언트만 들고 있음
- 클라이언트가 Authorization Code와 함께 서버에 POST 요청 시, code verifier 값을 같이 전송
- 서버가 code verifier 값을 보고 올바른 클라이언트라면 access token을 내려줌
* 공격자가 code_challenge 값을 클라이언트의 GET 요청에서 얻을 수 있지만, code_challenge는 code_verifier로 부터 <단방향 해시함수>(SHA 256 등)로 만들어졌기 때문에 code_challenge로부터 code_verifier를 유추할 수는 없음
728x90
반응형