Protocol Endpoints

RFC 6749에는 Authorization Server에 2개의 엔드포인트와 Client에 1개의 엔드포인트를 정의하고 있다. 이 엔드포인트들의 역할은 결국 Access Token이다.

Client가 Access Token을 얻기 위해 권한을 획득하는 방법을 RFC 6749에서는 4가지로 정의하지만, 우리는 Authorization Code와 Implict만을 구현하기로 했기 때문에 앞으로 두 방식만 살펴볼 것이다.

Authorization Server

Authorization Endpoint

Resource Owner의 인증 엔드포인트다.

보통 Client에서 Resource Owner는 SNS로그인 버튼 등을 클릭하여 Authorization Server로 이동하게 된다. Client는 Resource Owner가 Authorization Server로 이동할 때 추가 정보들을 URI에 바인딩해서 이동하게 해야하는데, 이 자세한 정보들은 다음 챕터에서 알아볼 것이다.

Token Endpoint

Client가 Access Token을 얻는 엔드포인트다. Authorization Code 방식으로 권한을 얻은 경우, 해당 코드로 Access Token과 Refresh Token을 얻는 엔드포인트며, Implict로 권한을 얻는 경우에는 Access Token을 같이 받아오기 때문에, Refresh Token을 이용해서 새로운 Access Token을 얻는 경우에 사용될 것이다.

이 때, Access Token을 얻기 위한 정보는 반드시 POST 메서드로 요청을 해야한다.

Client

Redirection Endpoint

Resource Owner가 Authorization Endpoint에서 인증에 성공하면 Authorization Server에서 다시 Client로 Resource Owner를 리다이렉트 시킬 것이다. 이 때, 이 엔드포인트로 리다이렉션 된다.

이는 사전에 Client가 Authorization Server에 등록할 때 보통 정보를 입력하며, Resource Owner가 Authorization Server로 이동할 때 redirect_uri값과 함께 이동할 수 있다.

이 엔드포인트 경로에서 Client는 URI에 있는 Access Token값을 파싱할 텐데, 따라서 그 어떤 써드파티 스크립트보다도 이 Access Token값을 추출하는 스크립트가 먼저 실행되어야 한다.

또한, 만약 엔드포인트가 유효하지 않은 경우 Resource Owner를 유효하지 않은 엔드포인트로 리다이렉트 시키지 않고 경고메세지를 출력해줘야 한다.

Access Token Scope

Authorization Endpoint와 Token Endpoint는 scope 파라미터를 받을 수 있다. 이는 Access Token에 대한 scope를 질의하는 것이라고 생각하면 된다.

마찬가지로, Authorization Server는 응답시 scope를 응답해줘야 한다. 이 때의 scope값에는 Access Token의 scope가 된다.

scope값이 없는 경우 Authorization Server의 정책에 따라 기본 scope값으로 간주해도 되고, Access Token의 scope와 요청시의 scope가 다르면 에러를 응답해주면서 현재 Access Token의 유효 scope를 응답해줘야 한다.

다음엔

이번 챕터에서는 Resource Owner, Client, Authorization Server간의 상호작용에 필요한 엔드포인트와 짧막한 정보에 대해 알아보았다. 다음 챕터는 이런 엔드포인트간의 상세한 Flow를 알아보도록 하겠다.