最近研究 CloudFoudry 需要了解 UAA 相关东西, 并学习了 OAuth 的相关知识. 在网上找到两篇文章写得比较好
[1] http://blog.gopivotal.com/cloud-foundry-pivotal/products/open-standards-in-cloud-foundry-identity-services
[2] http://tutorials.jenkov.com/oauth2/index.html
Summary
Authorization Code 方式是最完整的, Client Application 会被重定向到 OAuth Server 登录并同意授权, 之后再返回业务系统, 业务系统通过 Authorization Code 在 OAuth Server 处获取访问最终 Resource Server 的 Access Token
Implicit 与 Authorization Code 大体类似, 只是少了用 Auhtorization Code 获取 AccessToken 的步骤
Resource Owner 方式是客户程序知道用户名和密码, 认证时连同自身的 Client ID 和密码一起发送到 OAuth Server, 比如 CF Java 客户端就是使用这种方式
Client Credentials 是 Client Application 本身就类似于 Resource Owner
1. OAuth Client 首先需要在 OAuth Server 注册, 需要提供一个 Redirect URL, 并从 OAuth Server 获取 Client ID 和 Client 密码
2. 基本流程
a. 用户访问客户端应用程序
b. 客户端应用重定向到 OAuth Server
c. 用户输入用户名和密码登录, OAuth Server 执行完 Authentication 后, 会提示用户是否允许访问数据
d. OAuth Server 使用注册的重定向 URL, 用户再次被定向到客户端应用程序, 此时 URL 会包含 Authentication Code
e. 客户端应用程序接收到请求后, 使用 Authentication Code/Client ID/Client Password 访问 OAuth Server 获取 Access Token
3. OAuth 中四个角色
a. Resource Owner : One person or one application
b. Resource Server
c. Client Application
d. Authorization Server
* b 和 d 可以在一起, OAuth 规范未作详细规定, 其之间如何交互也无规定
4. OAuth Client 类型
a. Confidential
b. Public
OAuth 客户端需要持用 Client ID 和 Client Password, 两种类型的区别在于, 第三方是否可以通过某种方式获取该信息.
5. Client Profile
a. Web Application 指运行在 Web 服务器上的 Web 应用, 实际场景中, 还可能包含客户端浏览器
b. User Agent 比如运行在浏览器中的 JavaScript 应用
c. Native 比如桌面应用或者移动手机应用
6. OAuth 2.0 Authorization
a. 注册到 OAuth 服务器, 一般执行一次, Client Application 会获取分配的 Client ID 和 Client Password. 注册过程中, Client Application 需要提供 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.
b. 无论何时 Client Application 请求 Resource Server 上的资源时, Client Application 都需要到 OAuth Server 处使用 ID 和 密码执行认证
7. Authorization Grant 指 Resource Owner 授予 Client Application. OAuth 2.0 定义了如何类型 :
a. Authorization Code
b. Implicit
c. Resource Owner Password Credentials
d. Client Credentials
8. Authorization Code
a. 当 Client Application 重定向到 OAuth Server 时, Client ID 也会被传递过去, 这样 Authorization Server 可以知道哪个应用 (Client Application) 试图访问受保护资源
b. 当用户成功登录并授权访问后, OAuth Server 会使用 Client Application 注册时提供的 Redirect URI, 同时包含 Authentication Code.
c. Client Application 使用 Authentication Code, Client ID 和 Client Password 直接访问 Authorization Server, 并过去 Access Token. Access Token 代表 Client Application 通过认证和授权访问保护资源. (The access token serves as both authentication of the client, and authorization to access the resources. )
9. Implicit 与 Authentication Code 工作方式类似, 区别在于重定向时, Access Token 被包含在内.
a. 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.
b. 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.
c. 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.
d. 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.
10. Resource Owner Password Credentials 等价于, 用户 (Resource Owner) 把用户名密码告诉 Client Application, 然后 Client Application 直接使用用户名和密码访问 Resource Server
a. 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.
b. 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.
c. The resource owner password credentials would normally be used by user agent client applications, or native client applications.
11. Client Credentials 使用 Client Application 需要调用 Resource Server 提供的一些功能, 但这些功能不和任何 Resource Owner 相关
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.
12. OAuth 2.0 Endpoints
a. Authorization Endpoint
The authorization endpoint is the endpoint on the authorization server where the resource owner logs in, and grants authorization to the client application.
b. Token Endpoint
The token endpoint is the endpoint on the authorization server where the client application exchanges the authorization code, client ID and client secret, for an access token.
c. Redirection Endpoint
The redirect endpoint is the endpoint in the client application where the resource owner is redirected to, after having granted authorization at the authorization endpoint.
a 和 b 位于 Authorization Server 上, c 位于客户端应用程序上
13. Authorization Code Grant Requests/Responses
a. Authorization Request
a1. response_type Required. Must be set to code
a2. client_id Required. The client identifier as assigned by the authorization server, when the client was registered.
a3. redirect_uri Optional. The redirect URI registered by the client.
a4. scope Optional. The possible scope of the request.
a5. state Optional (recommended). Any client state that needs to be passed on to the client request URI.
b. Authorization Response
The authorization response contains the authorization code needed to obtain an access token. Here are the parameters included in the response:
b1. code Required. The authorization code.
b2. state Required, if present in request. The same value as sent by the client in the state parameter, if any.
c. Authorization Error Response
If an error occurs during authorization, two situations can occur.
The first is, that the client is not authenticated or recognized. For instance, a wrong redirect URI was sent in the request. In that case the authorization server must not redirect the resource owner to the redirect URI. Instead it should inform the resource owner of the error.
The second situation is that client is authenticated correctly, but that something else failed. In that case the following error response is sent to the client, included in the redirect URI:
c1. error Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
c2. error_description Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
c3. error_uri Optional. A URI pointing to a human-readable web page with information about the error.
c4. state Required, if present in authorization request. The same value as sent in the state parameter in the request.
d. Token Request
Once an authorization code is obtained, the client can use that code to obtain an access token. Here is the access token request parameters:
d1. grant_type Required. Must be set to authorization_code .
d2. code Required. The authorization code received by the authorization server.
d3. redirect_uri Required, if the request URI was included in the authorization request. Must be identical then.
e. Token Response
The response to the access token request is a JSON string containing the access token plus some more information:
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}
e1. The access_token property is the access token as assigned by the authorization server.
e2. The token_type property is a type of token assigned by the authorization server.
e3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.
e4. The refresh_token property contains a refresh token in case the access token can expire. The refresh token is used to obtain a new access token once the one returned in this response is no longer valid.
14. Implicit Grant Request
a. The implicit grant request contains the following parameters:
a1. response_type Required. Must be set to token .
a2. client_id Required. The client identifier as assigned by the authorization server, when the client was registered.
a3. redirect_uri Optional. The redirect URI registered by the client.
a4. scope Optional. The possible scope of the request.
a5. state Optional (recommended). Any client state that needs to be passed on to the client request URI.
b.Implicit Grant Response
The implicit grant response contains the following parameters. Note, that the implicit grant response is not JSON.
b1. access_token Required. The access token assigned by the authorization server.
b2. token_type Required. The type of the token
b3. expires_in Recommended. A number of seconds after which the access token expires.
b4. scope Optional. The scope of the access token.
b5. state Required, if present in the autorization request. Must be same value as state parameter in request.
c. Implicit Grant Error Response
If an error occurs during authorization, two situations can occur.
The first is, that the client is not authenticated or recognized. For instance, a wrong redirect URI was sent in the request. In that case the authorization server must not redirect the resource owner to the redirect URI. Instead it should inform the resource owner of the error.
The second situation is that client is okay, but that something else happened. In that case the following error response is sent to the client, included in the redirect URI:
c1. error Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
c2. error_description Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
c3. error_uri Optional. A URI pointing to a human-readable web page with information about the error.
c4. state Required, if present in authorization request. The same value as sent in the state parameter in the request.
15. Credentials Grant - Requests and Response
a. Resource Owner Password Credentials Grant Request
The request contains the following parameters:
a1. grant_type Required. Must be set to password
a2. username Required. The username of the resource owner, UTF-8 encoded.
a3. password Required. The password of the resource owner, UTF-8 encoded.
a4. scope Optional. The scope of the authorization.
b. Resource Owner Password Credentials Grant Response
The response is a JSON structure containing the access token. The JSON structure looks like this:
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}
b1. The access_token property is the access token as assigned by the authorization server.
b2. The token_type property is a type of token assigned by the authorization server.
b3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.
b4. The refresh_token property contains a refresh token in case the access token can expire. The refresh token is used to obtain a new access token once the one returned in this response is no longer valid.
16. Client Credentials Grant - Requests and Response
a. The client credentials grant request contains the following parameters:
a1. grant_type Required. Must be set to client_credentials .
a2. scope Optional. The scope of the authorization.
b. Client Credentials Grant Response
The client credentials response contains the following parameters:
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
}
b1. The access_token property is the access token as assigned by the authorization server.
b2. The token_type property is a type of token assigned by the authorization server.
b3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.
A refresh token should not be included for this type of authorization request.