OAuth 2.0 授权

内容表

• Client ID, Client Secret and Redirect URI
• Authorization Grant
• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

When a client applications wants access to the resources of a resource owner, hosted on a resource server, the client application must first obtain an authorization grant. This text explains how such an application grant is obtained.

当一个客户端应用想获取资源拥有者的资源，这个资源托管在资源服务器上。客户端应用首先要获取授权许可。本篇章将解释一个客户端应用怎样获取许可。

Client ID, Client Secret and Redirect URI

Before a client application can request access to resources on a resource server, the client application must first register with the authorization server associated with the resource server.

在一个客户端应用可以请求获取在资源服务器上的资源。客户端应用必须首先在和资源服务器相关的认证服务器上注册。

The registration is typically a one-time task. Once registered, the registration remains valid, unless the client app registration is revoked.

注册时一个一次性的工作。一旦注册，注册一直有效，除非将注册的客户端app取消。

At registration the client application is assigned a client ID and a client secret (password) by the authorization server. The client ID and secret is unique to the client application on that authorization server. If a client application registers with multiple authorization servers (e.g. both Facebook, Twitter and Google), each authorization server will issue its own unique client ID to the client application.

在注册时，认证服务器将分配client ID和client secret给客户端应用。client ID 和 client secret 在那个授权服务上对客户端app是唯一的。如果客户端app注册多个认证服务器（比如Facebook，Google），每个授权服务将分配自己的唯一的client ID给客户端应用。

Whenever the client application requests access to resources stored on that same resource server, the client application needs to authenticate itself by sending along the client ID and the client secret to the autorhization server.

无论什么时候，客户端app请求获取资源服务的资源，客户端一个用需要通过发送自己的client ID 和client secret 到认证服务，认证自己。

During the registration the client also registers a redirect URI. This redirect URI is used when a resource owner grants authorization to the client application. When a resource owner has successfully authorized the client application via the authorization server, the resource owner is redirected back to the client application, to the redirect URI.

在注册阶段，客户端也注册一个重定向URI,当资源拥有者授权给客户端app时需要用中定向URI，当一个资源拥有者通过认证服务成功授权客户端app，资源拥有者被重定向回客户端app，也就是重定向URI。

授权许可

The authorization grant is given to a client application by the resource owner, in cooperation with the authorization server associated with the resource server.

The OAuth 2.0 specification lists four different types of authorization grants. Each type has different security characteristics. The authorization grant types are:

OAuth2.0规范列出了各种类型的授权许可，每种有不同的安全特性。授权许可种类有：

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

Each of these authorization grant types is covered in the following sections.

每种授权许可类型将被包括在下面的章节中：

An authorization grant using an authorization code works like this (the numbers correspond to the steps shown in the diagram below the description):

用授权码的授权许可类型运作如下：

1) The resource owner (user) accesses the client application.

资源拥有者获取客户端应用

2) The client application tells the user to login to the client application via an authorization server (e.g. Facebook, Twitter, Google etc.).

客户端应用告诉用户通过认证服务登（e.g. Facebook, Twitter, Google etc）录客户端应用

3) To login via the authorizaion server, the user is redirected to the authorization server by the client application. The client application sends its client ID along to the authorization server, so the authorization server knows which application is trying to access the protected resources.

通过认证服务登录，用户通过客户端app被重定向到认证服务器。客户端app将client ID 发送给认证服务。这样认证服务就知道了是那个客户端app想获取受保护的资源。

4) The user logs in via the authorization server. After successful login the user is asked if she wants to grant access to her resources to the client application. If the user accepts, the user is redirected back to the client application.

用户通过认证服务登录。成功登录后，用户处被询问是否愿意给与客户端访问自己资源的许可。如果用户介绍，用户将被重定向回客户端。

5) When redirected back to the client application, the authorization server sends the user to a specific redirect URI, which the client application has registered with the authorization server ahead of time. Along with the redirection, the authorization server sends an authorization code, representing the authorization.

当被重定向回客户端,认证服务将用户重定向到重定向URI，这个URI就是客户端app之前在认证服务器注册时提供的。在重定向的同时，认证服务发送一个认证code，表示认证。

6) When the redirect URI in the client application is accessed, the client application connects directly to the authorization server. The client application sends the authorization code along with its own client ID and and client secret.

当在客户端app中重定向URI被获取后，客户端app直接连接认证服务。客户端app发送认证code以及client ID 和client secret。

7) If the authorization server can accept these values, the authorization server sends back an access token.

如果认证服务接受这些值，认证服务返回一个access token。

10) The client application can now use the access token to request resources from the resource server. The access token serves as both authentication of the client, resource owner (user) and authorization to access the resources.

客户端应用现在可以用access token获取在资源服务器上的资源。 access token 代表客户端认证，资源拥有者，对资源的授权。

Here is a diagram illustrating the authorization process when using authorization code to authorize a client application:

这个图描述了当应用授权码授权一个客户端的过程：

Authorization grant via authorization code.

Implicit

An implicit authorization grant is similar to an authorization code grant, except the access token is returned to the client application already after the user has finished the authorization. The access token is thus returned when the user agent is redirected to the redirect URI.

This of course means that the access token is accessible in the user agent, or native application participating in the implicit authorization grant. The access token is not stored securely on a web server.

Furthermore, the client application can only send its client ID to the authorization server. If the client were to send its client secret too, the client secret would have to be stored in the user agent or native application too. That would make it vulnerable to hacking.

Implicit authorization grant is mostly used in a user agent or native client application. The user agent or native application would receive the access token from the authorization server.

Here is an illustration of implicit authorization grant:

Implicit authorization grant.

Resource Owner Password Credentials

The resource owner password credentials authorization grant method works by giving the client application access to the resource owners credentials. For instance, a user could type his Twitter user name and password (credentials) into the client application. The client application could then use the user name and password to access resources in Twitter.

Using the resource owner password credentials requires a lot of trust in the client application. You do not want to type your credentials into an application you suspect might abuse it.

The resource owner password credentials would normally be used by user agent client applications, or native client applications.

Client Credentials

Client credential authorization is for the situations where the client application needs to access resources or call functions in the resource server, which are not related to a specific resource owner (e.g. user). For instance, obtaining a list of venues from Foursquare. This does not necessary have anything to do with a specific Foursquare user.