Design

OAuth 2.0

 · 7 mins read

What is OAuth 2.0

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

Roles

OAuth defines four roles:

  • resource owner An entity capable of granting access to a protected resource.

    When the resource owner is a person, it is referred to as an

    end-user.

  • resource server

    The server hosting the protected resources, capable of accepting

    and responding to protected resource requests using access tokens.

  • client

    An application making protected resource requests on behalf of the

    resource owner and with its authorization. The term “client” does

    not imply any particular implementation characteristics (e.g.,

    whether the application executes on a server, a desktop, or other

    devices).

  • authorization server

    The server issuing access tokens to the client after successfully

    authenticating the resource owner and obtaining authorization.

The interaction between the authorization server and resource server is beyond the scope of this specification. The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.

Work flow

THis work flow is a snapshot of RFC6749.

</p>

(A)  The client requests authorization from the resource owner.  The
        authorization request can be made directly to the resource owner
        (as shown), or preferably indirectly via the authorization
        server as an intermediary.

   (B)  The client receives an authorization grant, which is a
        credential representing the resource owner's authorization,
        expressed using one of four grant types defined in this
        specification or using an extension grant type.  The
        authorization grant type depends on the method used by the
        client to request authorization and the types supported by the
        authorization server.

   (C)  The client requests an access token by authenticating with the
        authorization server and presenting the authorization grant.

   (D)  The authorization server authenticates the client and validates
        the authorization grant, and if valid, issues an access token.

   (E)  The client requests the protected resource from the resource
        server and authenticates by presenting the access token.

   (F)  The resource server validates the access token, and if valid,
        serves the request.

</p>

Authorization Grant

An authorization grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types：

  • authorization code The authorization code is obtained by using an authorization server

    as an intermediary between the client and resource owner. Instead of

    requesting authorization directly from the resource owner, the client

    directs the resource owner to an authorization server (via its

    user-agent as defined in [RFC2616]), which in turn directs the

    resource owner back to the client with the authorization code.

    Before directing the resource owner back to the client with the

    authorization code, the authorization server authenticates the

    resource owner and obtains authorization. Because the resource owner

    only authenticates with the authorization server, the resource

    owner’s credentials are never shared with the client.

  • implicit

    The implicit grant is a simplified authorization code flow optimized

    for clients implemented in a browser using a scripting language such

    as JavaScript. In the implicit flow, instead of issuing the client

    an authorization code, the client is issued an access token directly.

  • resource owner password credentials

    The resource owner password credentials (i.e., username and password)

    can be used directly as an authorization grant to obtain an access

    token. The credentials should only be used when there is a high

    degree of trust between the resource owner and the client.

  • client credentials

    Client credentials are used as an authorization grant

    typically when the client is acting on its own behalf (the client is

    also the resource owner) or is requesting access to protected

    resources based on an authorization previously arranged with the

    authorization server.

Refresh Token

Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.

Client Registration

Before initiating the protocol, the client registers with the authorization server. The means through which the client registers with the authorization server are beyond the scope of this specification but typically involve end-user interaction with an HTML registration form.

Client Types

OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):

  • confidential

Clients capable of maintaining the confidentiality of their credentials

– public

Clients incapable of maintaining the confidentiality of their credentials

Client Identifier

The authorization server issues the registered client a client identifier — a unique string representing the registration information provided by the client.

Client Authentication

If the client type is confidential, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server.

Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g., password, public/private key pair).

  • client_id

REQUIRED. The client identifier issued to the client during

the registration process described above.

– client_secret

REQUIRED. The client secret. The client MAY omit the

parameter if the client secret is an empty string.

Attention: The authorization server MUST require the use of TLS when sending requests using password authentication.

Authorization Code Grant

Authorization Request

  • response_type

REQUIRED. Value MUST be set to “code”.

  • client_id

REQUIRED. The client identifier

  • redirect_uri

OPTIONAL. The Redirect URI

  • scope

OPTIONAL. The scope of the access request

  • state

RECOMMENDED. An opaque value used by the client to maintain

state between the request and callback. The authorization

server includes this value when redirecting the user-agent back

to the client. The parameter SHOULD be used for preventing

cross-site request forgery.

Authorization Response

  • code

REQUIRED. The authorization code generated by the

authorization server. The authorization code MUST expire

shortly after it is issued to mitigate the risk of leaks. A

maximum authorization code lifetime of 10 minutes is

RECOMMENDED. The client MUST NOT use the authorization code more than once. If an authorization code is used more than

once, the authorization server MUST deny the request and SHOULD

revoke (when possible) all tokens previously issued based on

that authorization code. The authorization code is bound to

the client identifier and redirection URI.

  • state

REQUIRED if the “state” parameter was present in the client

authorization request. The exact value received from the

client.

For example, the request

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

the reponse

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
       &state=xyz

Access Token Request

  • grant_type

REQUIRED. Value MUST be set to “authorization_code”.

  • code

REQUIRED. The authorization code received from the

authorization server.

  • redirect_uri

REQUIRED, if the “redirect_uri” parameter was included in the

authorization request , and their values MUST be identical.

  • client_id

REQUIRED, if the client is not authenticating with the

authorization server

For example,

the request

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

the response

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}

Implicit Grant

Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.

1.oauth2

2.RFC6749