最近研究 CloudFoudry 需要了解 UAA 相關(guān)東西, 并學(xué)習(xí)了 OAuth 的相關(guān)知識(shí). 在網(wǎng)上找到兩篇文章寫(xiě)得比較好
[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 會(huì)被重定向到 OAuth Server 登錄并同意授權(quán), 之后再返回業(yè)務(wù)系統(tǒng), 業(yè)務(wù)系統(tǒng)通過(guò) Authorization Code 在 OAuth Server 處獲取訪問(wèn)最終 Resource Server 的 Access Token
Implicit 與 Authorization Code 大體類似, 只是少了用 Auhtorization Code 獲取 AccessToken 的步驟
Resource Owner 方式是客戶程序知道用戶名和密碼, 認(rèn)證時(shí)連同自身的 Client ID 和密碼一起發(fā)送到 OAuth Server, 比如 CF Java 客戶端就是使用這種方式
Client Credentials 是 Client Application 本身就類似于 Resource Owner
1. OAuth Client 首先需要在 OAuth Server 注冊(cè), 需要提供一個(gè) Redirect URL, 并從 OAuth Server 獲取 Client ID 和 Client 密碼
2. 基本流程
a. 用戶訪問(wèn)客戶端應(yīng)用程序
b. 客戶端應(yīng)用重定向到 OAuth Server
c. 用戶輸入用戶名和密碼登錄, OAuth Server 執(zhí)行完 Authentication 后, 會(huì)提示用戶是否允許訪問(wèn)數(shù)據(jù)
d. OAuth Server 使用注冊(cè)的重定向 URL, 用戶再次被定向到客戶端應(yīng)用程序, 此時(shí) URL 會(huì)包含 Authentication Code
e. 客戶端應(yīng)用程序接收到請(qǐng)求后, 使用 Authentication Code/Client ID/Client Password 訪問(wèn) OAuth Server 獲取 Access Token
3. OAuth 中四個(gè)角色
a. Resource Owner : One person or one application
b. Resource Server
c. Client Application
d. Authorization Server
* b 和 d 可以在一起, OAuth 規(guī)范未作詳細(xì)規(guī)定, 其之間如何交互也無(wú)規(guī)定
4. OAuth Client 類型
a. Confidential
b. Public
OAuth 客戶端需要持用 Client ID 和 Client Password, 兩種類型的區(qū)別在于, 第三方是否可以通過(guò)某種方式獲取該信息.
5. Client Profile
a. Web Application 指運(yùn)行在 Web 服務(wù)器上的 Web 應(yīng)用, 實(shí)際場(chǎng)景中, 還可能包含客戶端瀏覽器
b. User Agent 比如運(yùn)行在瀏覽器中的 JavaScript 應(yīng)用
c. Native 比如桌面應(yīng)用或者移動(dòng)手機(jī)應(yīng)用
6. OAuth 2.0 Authorization
a. 注冊(cè)到 OAuth 服務(wù)器, 一般執(zhí)行一次, Client Application 會(huì)獲取分配的 Client ID 和 Client Password. 注冊(cè)過(guò)程中, 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. 無(wú)論何時(shí) Client Application 請(qǐng)求 Resource Server 上的資源時(shí), Client Application 都需要到 OAuth Server 處使用 ID 和 密碼執(zhí)行認(rèn)證
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. 當(dāng) Client Application 重定向到 OAuth Server 時(shí), Client ID 也會(huì)被傳遞過(guò)去, 這樣 Authorization Server 可以知道哪個(gè)應(yīng)用 (Client Application) 試圖訪問(wèn)受保護(hù)資源
b. 當(dāng)用戶成功登錄并授權(quán)訪問(wèn)后, OAuth Server 會(huì)使用 Client Application 注冊(cè)時(shí)提供的 Redirect URI, 同時(shí)包含 Authentication Code.
c. Client Application 使用 Authentication Code, Client ID 和 Client Password 直接訪問(wèn) Authorization Server, 并過(guò)去 Access Token. Access Token 代表 Client Application 通過(guò)認(rèn)證和授權(quán)訪問(wèn)保護(hù)資源. (The access token serves as both authentication of the client, and authorization to access the resources. )
9. Implicit 與 Authentication Code 工作方式類似, 區(qū)別在于重定向時(shí), Access Token 被包含在內(nèi).
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 等價(jià)于, 用戶 (Resource Owner) 把用戶名密碼告訴 Client Application, 然后 Client Application 直接使用用戶名和密碼訪問(wèn) 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 需要調(diào)用 Resource Server 提供的一些功能, 但這些功能不和任何 Resource Owner 相關(guān)
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 位于客戶端應(yīng)用程序上
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.