OAuth 2.0, Grant Type 개념 정리

grant_type

  • OAuth 2.0 프레임워크의 핵심은 다양한 클라이언트 환경에 적합한 인증 및 권한의 위임 방법(grant_type)을 제공하고 그 결과로 클라이언트에게 access_token을 발급하는 것이다.

  • 한 번 획득된 access_token은 만료 시점까지 모든 리소스 서버의 엔드포인트 요청 헤더에 Authorization: Bearer {ACCESS_TOKEN}로 첨부된다.

  • 사용자의 인증 과정에 개입하는 2가지 방식(authorization_code, implicit)과 사용자가 인증 과정에 개입하지 않는 2가지 방식(password, client_credentials)이 있다. 마지막으로 만료된 access_token을 재발급 받기 위한 refresh_token이 있다.

implicit

  • implicitauthorization_code과 같이 인증 과정에서 사용자의 로그인 및 권한 동의를 요구하는 타입이다.

  • implicit은 웹 서버가 아닌 모바일 네이티브 앱 및 브라우저 기반의 JS 애플리케이션(SPA)에 가장 적합하도록 설계된 grant_type타입이다.

  • authorization_code와의 차이점이라면 response_type으로 code가 아닌 token을 요청하고 반환한다는 것이다. 사용자가 로그인 및 권한 위임에 동의하면 redirect_uritoken 파라메터를 통해 access_token을 바로 내려준다.

  • 이 방식은 access_token이 그대로 사용자(또는 외부)에게 노출된다. 유효한 클라이언트인지 확인할 방법은 redirect_uri 뿐이다. (절대 사용자(외부)에 노출되지 않아야 할 client_secret은 전혀 사용되지 않는다.)

  • refresh_token 또한 노출되지 않아야 하기 때문에 발급되지 않는다. 따라서 access_token이 만료되면 같은 인증 과정을 반복해야 한다. (Azure AD같은 서비스는 iframe에 세션 쿠키를 유지하는 방법으로 이러한 인증 과정을 생략하기도 한다.)

  • [1단계] 클라이언트가 인증 서버에게 사용자 로그인 및 권한 동의 웹 페이지를 요청한다. GET /oauth/authorize?response_type=token&client_id={CLINET_ID}&redirect_uri={CALLBACK_URL}&scope={SCOPE} Yahoo와 같이 다국어 지원 API들은 language 파라메터를 옵션으로 요청 받기도 한다.

  • [2단계] 1단계 성공시 POST {CALLBACK_URL}#token={ACCESS_TOKEN}으로 리다이렉트한다. 이 시점에 클라이언트는 access_token을 획득하게 된다.

  • [3단계] 획득한 access_token으로 리소스 서버의 엔드포인트로 API를 요청한다.

password

  • password는 사용자의 인증 정보를 클라이언트로부터 보호하는 authorization_code, implicit과 다르게 클라이언트가 이미 사용자의 인증 정보를 알고 있을 경우 사용할 수 있는 타입이다. 클라이언트가 매우 신뢰할 수 있는 경우에 사용한다. [관련 링크]


  • POST /oauth/token 요청으로 바로 access_token을 획득한다. 필수로 요구되는 파라메터는 client_id, client_secret, grant_type = password, username, password이다.

참고 글

저작자 표시 비영리 동일 조건 변경 허락
신고