OAuth2.0

 

grant_type

 

간단흐름(쿠팡기준으로 설명 grant_type = password기준)

• 고객, 앱, 앱개발자, 인증서버, 자원서버(api서버) 이렇게 5가지 주체가 있다.
• 앱개발자는 인증서버에 admin페이지에서 client_id/secret_id를 발급받는다. (고객이 발급받는게 아님에 주의)
• 앱에서 고객이 id/pwd를 넣고 로그인하면(인증서버에 api를 보내면) 인증서버에는 고객id/고객pwd, (앱개발자가앱에넣은) client_id/secret_id 이렇게 4가지 정보를 받는다. 모두 이상 없는경우 앱에게 access token을 넘겨준다. 
• 그럼 앱은 고객에게 권한을 위임받는 것이고, 이 이후로는 특정시간동안 자원서버에 access token을 보내서 api호출이 가능하다.
• 하지만 이 방식은 앱이 고객의 비밀번호를 직접 다루게 되므로 보안상 위험이 커서, 요즘은 거의 사용되지 않는다.

grant_type = authorization_code

• 앱에서 고객 id/pwd를 받고 인증서버에 api로 전달하는게 위험하니..
• 앱이 아닌 인증서버쪽 로그인 화면으로 url redirect를 시키는게 authrization_code방식이다.
• 로그인후에 앱에 다시 인증코드가 담긴 url을 불러주면
• 앱은 짧은 생명주기를 가진 이 인증코드로 서버에 api호출을 해서 access token을 받아온다.
• (딥링크 방식에서도 이 인증코드 → access token 교환 구조가 유사하게 사용된다.)

grant_type = client_credentials

• 서버 간(M2M) 통신 – 사용자 개입 없이 서비스 간 호출

 

PKCE(Proof Key for Code Exchange)

PKCE는 공개 클라이언트에서 Authorization Code Grant를 안전하게 사용할 수 있게 해주는 확장입니다.
클라이언트가 매 인가 요청 시 고유한 code_verifier를 만들고, 이를 SHA-256 해시한 code_challenge를 전달합니다.
토큰 발급 단계에서 클라이언트는 원본 code_verifier를 보내고, 인증 서버는 해시 값을 비교해 검증합니다.
이렇게 함으로써 인가 코드가 중간에 탈취되더라도, 올바른 code_verifier 없이는 토큰을 발급받을 수 없게 되어 보안성이 크게 향상됩니다.PKCE는 RFC 7636에 정의되어 있으며, 요즘은 SPA·모바일 앱용 OAuth 표준으로 자리 잡았습니다.

(모바일앱의 경우 client_secret을 탈취할 가능성이 커서 따로 저장하지 않기 위함)

 

state 검증

CSRF 공격 방지를 위해 인가 요청 시 생성한 state 값을 콜백에서 체크

인가요청시 state=난수를 client가 넣고, 콜백에서도 전달받는 state가 그 난수가 맞는지 체크.