RFC 6749 - 1장 Introduction

Introduction

전통적인 client-server authentication model에서 third-party 애플리케이션이 restricted resource (protected resource)에 접근하기 위해서는 resource owner의 credentials를 알아야만 했다.

이는 third-party 애플리케이션이 resource owner의 password를 저장하거나, 접근할 수 있는 resource의 scope을 제한할 수 없는 등 보안적으로 취약하다.

OAuth는 authorization layer를 도입하고, 클라이언트의 역할을 resource owner의 역할과 분리하여 이러한 문제를 해결한다.

클라이언트는 resource owner의 승인 하에 resource owner의 credentials 대신 authorization server로부터 발급된 access token이라는 scope, lifetime 등을 가진 다른 set of credentials을 통해 protected resource에 접근한다.

Roles

OAuth는 네 가지 역할을 정의한다.

• resource owner

  • protected resource에 대한 엑세스를 부여할 수 있는 entity이다.
  • resource owner가 사람인 경우, end-user라고 부른다.

• resource server

  • protected resource의 호스팅 서버로, access token을 사용하여 protected resource에 대한 요청에 응답할 수 있다.

• client

  • resource owner를 대신하여 protected resource에 대한 요청을 하는 애플리케이션이다.

• authorization server

  • resource owner를 인증하고 권한을 얻은 후 client에 access token을 발급하는 서버이다.

authorization server와 resource server간의 상호 작용은 이 사양의 범위를 벗어난다. authorization server와 resource server는 동일한 서버이거나 별도의 엔티티일 수 있다. 한 authorization server는 여러 resource server에서 허용하는 access token을 발급할 수 있다.

Protocol Flow

1. Client -> Resource Owner : Authorization Request
2. Resource Owner -> Client : Authorization Grant
3. Client -> Authorization Server : Authorization Grant
4. Authorization Server -> Client : Access Token
5. Client -> Resource Server : Access Token
6. Resource Server -> Client : Protected Resource

Authorization Grant

authorization grant는 client가 access token을 발급 받기 위해 resource owner의 권한을 나타내는 credential이다.

grant types은 4가지 이며 확장 가능하다.

• authorization code
• implicit
• resource owner password credentials
• client credentials

Authorization Code

Client가 직접 resource owner에게 권한을 요청하는 대신 authorization server로 안내하면 authorization server가 resource owner를 인증하고 authorization code와 함께 client로 다시 리다이렉트한다.

authorization server가 client를 인증할 수 있다는 점, access token이 user-agent에 남지 않는다는 점 등 몇 가지 보안적인 이점이 있다.

Implicit

스크립트 언어로 구현된 client를 위해 최적화 된 단순화된 authorization code flow이다. authorization code 발급 없이 resource owner 인증 후 바로 access token을 발급한다.

authorization server가 client를 인증하지는 않는다. redirection URI를 통해 client identity를 증명할 수도 있지만 이 경우 access token이 user-agent를 통해 노출될 수 있다.

in-browser application 같은 클라이언트의 응답성과 효율성을 위해 사용된다. access token을 얻는 데 필요한 왕복 횟수를 줄여주기 때문이다.

Resource Owner Password Credentials

username과 password 같은 resource owner password credentials는 access token을 얻는데에 직접 사용될 수 있다. resource owner와 client 간에 신뢰 수준이 높은 경우와 다른 grant type을 사용할 수 없는 경우에만 사용해야 한다.

resource owner의 credentials에 대해서는 한 번 접근하고 이후 long-lived access token이나 refresh token을 사용함으로서 resource owner의 credentials를 저장하지 않도록 설계할 수 있다.

Client credentials

scope이 client 제어 하에 있는 리소스로 제한되거나 이전에 authorization server와 합의된 리소스에 대해서만 사용 가능하다. 일반적으로 client가 resource owner일 때 또는 authorization server와 미리 합의된 권한에 따라 리소스에 접근할 때 사용한다.

Access Token

protected resource에 접근하는데 사용되는 credentials로 client에 발급된 권한을 나타내는 문자열이다. 특정한 scope과 duration을 갖는다. 인가 정보를 가져오는데에 쓰이는 id일 수도 있고, 다양한 방식으로 인가 정보를 token string에 포함할 수도 있다.

access token은 abstraction layer로 제한된 엑세스만을 제공하며, resource server의 인가 방식을 한 가지로 단순화한다.

access token은 다양한 포맷, 구조, 암호화 등 활용 방법을 가질 수 있다. (RFC6750)

Refresh Token

동일하거나 더 좁은 범위의 새 access token을 얻는 데 사용되는 credentials이다. authorization server에서 optional로 제공하며, 발급하는 경우 access token을 발급할 때 포함시킨다. access token과 달리 refresh token은 resource server로는 전달하지 않고 authorization server에서만 사용한다.