Client Registration

Client는 OAuth 2.0 프로토콜을 개시하기에 앞서, Authorization Server에 등록이 되어있어야 한다. 이러한 등록 방법은 RFC 6749에서 정의하지는 않지만, 가장 일반적인 방법은 HTTP 폼을 이용하는 것이다.

더 나아가 굳이 Client와 Authorization Server가 직접적으로 등록절차를 밟을 필요도 없다. 예를 들어 Authorization Server가 Client를 신뢰할만한 채널에서 직접 찾을 수도 있다. 하지만 우리는 가장 일반적인 방법인 HTTP 폼을 이용하는 방법으로 구현할 것이다.

Register information

Authorization Server에 등록할 때, Client는 다음과 같은 정보를 입력해야 한다.

• Client Type
• Redirection URI
• 그 외 Authorization Server에서 필요로 하는 정보

Client Types

RFC 6749에서는 다음과 같이 2가지 종류의 Client Type을 정의하고 있다.

confidential

Client가 credential을 안전하게 보관할 수 있는 경우

• 일반적인 웹어플리케이션의 경우, 웹서버에서 실행되므로 자격증명을 안전하게 보관할 수 있다.

public

Client가 credential을 안전하게 보관할 수 없는 경우

• 자바스크립트 어플리케이션
• 모바일 어플리케이션
• 그 외 Resource Owner에서 실행되어 코드가 유출될 수 있는 경우

Client Identifier

Authorization Server는 각 Client를 구분하기 위한 문자열이 필요하다. 이 문자열은 유출되어도 상관 없는 값이므로, 안전하게 보관할 필요는 없다. 다만 그렇기 때문에 Authorization Server는 이 값만으로 Client 인증을 처리하면 안 된다.

이 문자열에 대한 길이는 정의되어 있지 않다. Authorization Server가 적절하게 구현하면 되는데, 모든 Client를 고유하게 구분할 수 있음을 감안하고 길이를 정의해야 된다.

또, 되도록이면 Authorization Server는 이 값을 Client가 확인할 수 있도록 문서화 해주는 것이 좋다.

Client Authentication

클라이언트 등록절차 결과로 받은 credential값으로 Client는 Authorization Server에서 요구하는 방법으로 인증 절차를 밟을 수 있다.

Client Password

일반적인 경우 credential 값은 비밀번호와 같은 특정 해쉬문자열일 수 있다. 외부 API서비스를 사용해본 개발자들은 알겠지만 대개 서비스에 등록을 하고 나면 API key값을 얻게 되는데, 이 값이 바로 RFC 6749에서 의미하는 Client Authentication을 위한 Client Password가 된다.

RFC 6749에서 Authorization Server가 반드시 구현해야하는 인증방법을 명시하는데, RFC 2617 - HTTP Authentication이 바로 그것이다.

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbU13

이 외에 request-body를 이용하는 방법으로도 구현할 수 있다. 이 때 parameter값은 아래와 같다.

• client_id
• client_secret

이 방법은 권장되지 않으며, 위에서 언급한 RFC 2617을 구현할 수 없는 Client에 한정해야한다. 또, 절대로 이 값이 URI에 노출되어선 안 된다.

다음엔

다음은 Protocol Endpoints에 대해 정리하도록 하겠다.