[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 鐨勬楠?br />Resource Owner 鏂瑰紡鏄鎴風▼搴忕煡閬撶敤鎴峰悕鍜屽瘑鐮? 璁よ瘉鏃惰繛鍚岃嚜韜殑 Client ID 鍜屽瘑鐮佷竴璧峰彂閫佸埌 OAuth Server, 姣斿 CF Java 瀹㈡埛绔氨鏄嬌鐢ㄨ繖縐嶆柟寮?br />Client Credentials 鏄?Client Application 鏈韓灝辯被浼間簬 Resource Owner
Implicit 涓?Authorization Code 澶т綋綾諱技, 鍙槸灝戜簡鐢?Auhtorization Code 鑾峰彇 AccessToken 鐨勬楠?br />Resource Owner 鏂瑰紡鏄鎴風▼搴忕煡閬撶敤鎴峰悕鍜屽瘑鐮? 璁よ瘉鏃惰繛鍚岃嚜韜殑 Client ID 鍜屽瘑鐮佷竴璧峰彂閫佸埌 OAuth Server, 姣斿 CF Java 瀹㈡埛绔氨鏄嬌鐢ㄨ繖縐嶆柟寮?br />Client Credentials 鏄?Client Application 鏈韓灝辯被浼間簬 Resource Owner
1. OAuth Client 棣栧厛闇瑕佸湪 OAuth Server 娉ㄥ唽, 闇瑕佹彁渚涗竴涓?Redirect URL, 騫朵粠 OAuth Server 鑾峰彇 Client ID 鍜?Client 瀵嗙爜
2. 鍩烘湰嫻佺▼
a. 鐢ㄦ埛璁塊棶瀹㈡埛绔簲鐢ㄧ▼搴?br /> b. 瀹㈡埛绔簲鐢ㄩ噸瀹氬悜鍒?OAuth Server
c. 鐢ㄦ埛杈撳叆鐢ㄦ埛鍚嶅拰瀵嗙爜鐧誨綍, OAuth Server 鎵ц瀹?Authentication 鍚? 浼氭彁紺虹敤鎴鋒槸鍚﹀厑璁歌闂暟鎹?br /> d. OAuth Server 浣跨敤娉ㄥ唽鐨勯噸瀹氬悜 URL, 鐢ㄦ埛鍐嶆琚畾鍚戝埌瀹㈡埛绔簲鐢ㄧ▼搴? 姝ゆ椂 URL 浼氬寘鍚?Authentication Code
e. 瀹㈡埛绔簲鐢ㄧ▼搴忔帴鏀跺埌璇鋒眰鍚? 浣跨敤 Authentication Code/Client ID/Client Password 璁塊棶 OAuth Server 鑾峰彇 Access Token
3. OAuth 涓洓涓鑹?br /> a. Resource Owner : One person or one application
b. Resource Server
c. Client Application
d. Authorization Server
* b 鍜?d 鍙互鍦ㄤ竴璧? OAuth 瑙勮寖鏈綔璇︾粏瑙勫畾, 鍏朵箣闂村浣曚氦浜掍篃鏃犺瀹?br />
4. OAuth Client 綾誨瀷
a. Confidential
b. Public
OAuth 瀹㈡埛绔渶瑕佹寔鐢?Client ID 鍜?Client Password, 涓ょ綾誨瀷鐨勫尯鍒湪浜? 絎笁鏂規槸鍚﹀彲浠ラ氳繃鏌愮鏂瑰紡鑾峰彇璇ヤ俊鎭?
5. Client Profile
a. Web Application 鎸囪繍琛屽湪 Web 鏈嶅姟鍣ㄤ笂鐨?Web 搴旂敤, 瀹為檯鍦烘櫙涓? 榪樺彲鑳藉寘鍚鎴風嫻忚鍣?nbsp;
b. User Agent 姣斿榪愯鍦ㄦ祻瑙堝櫒涓殑 JavaScript 搴旂敤
c. Native 姣斿妗岄潰搴旂敤鎴栬呯Щ鍔ㄦ墜鏈哄簲鐢?br />
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) 璇曞浘璁塊棶鍙椾繚鎶よ祫婧?br /> 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.
2. 鍩烘湰嫻佺▼
a. 鐢ㄦ埛璁塊棶瀹㈡埛绔簲鐢ㄧ▼搴?br /> b. 瀹㈡埛绔簲鐢ㄩ噸瀹氬悜鍒?OAuth Server
c. 鐢ㄦ埛杈撳叆鐢ㄦ埛鍚嶅拰瀵嗙爜鐧誨綍, OAuth Server 鎵ц瀹?Authentication 鍚? 浼氭彁紺虹敤鎴鋒槸鍚﹀厑璁歌闂暟鎹?br /> d. OAuth Server 浣跨敤娉ㄥ唽鐨勯噸瀹氬悜 URL, 鐢ㄦ埛鍐嶆琚畾鍚戝埌瀹㈡埛绔簲鐢ㄧ▼搴? 姝ゆ椂 URL 浼氬寘鍚?Authentication Code
e. 瀹㈡埛绔簲鐢ㄧ▼搴忔帴鏀跺埌璇鋒眰鍚? 浣跨敤 Authentication Code/Client ID/Client Password 璁塊棶 OAuth Server 鑾峰彇 Access Token
3. OAuth 涓洓涓鑹?br /> a. Resource Owner : One person or one application
b. Resource Server
c. Client Application
d. Authorization Server
* b 鍜?d 鍙互鍦ㄤ竴璧? OAuth 瑙勮寖鏈綔璇︾粏瑙勫畾, 鍏朵箣闂村浣曚氦浜掍篃鏃犺瀹?br />
4. OAuth Client 綾誨瀷
a. Confidential
b. Public
OAuth 瀹㈡埛绔渶瑕佹寔鐢?Client ID 鍜?Client Password, 涓ょ綾誨瀷鐨勫尯鍒湪浜? 絎笁鏂規槸鍚﹀彲浠ラ氳繃鏌愮鏂瑰紡鑾峰彇璇ヤ俊鎭?
5. Client Profile
a. Web Application 鎸囪繍琛屽湪 Web 鏈嶅姟鍣ㄤ笂鐨?Web 搴旂敤, 瀹為檯鍦烘櫙涓? 榪樺彲鑳藉寘鍚鎴風嫻忚鍣?nbsp;
b. User Agent 姣斿榪愯鍦ㄦ祻瑙堝櫒涓殑 JavaScript 搴旂敤
c. Native 姣斿妗岄潰搴旂敤鎴栬呯Щ鍔ㄦ墜鏈哄簲鐢?br />
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) 璇曞浘璁塊棶鍙椾繚鎶よ祫婧?br /> 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.
]]>
a.涓嶈鎶婁粬浠殑瑙ｅ喅鏂規硶璇涓烘槸闂鐨勫畾涔?BR> b.濡傛灉浣犲お杞繪槗鍦拌В鍐充簡浠栦滑鐨勯棶棰橈紝浠栦滑姘歌繙閮戒笉浼氱浉淇′綘鐪熺殑瑙ｅ喅浜嗕粬浠殑闂
c.浣犳案榪滈兘涓嶈兘鑲畾浣犲凡緇忔湁浜嗕竴涓紜殑瀹氫箟錛屽嵆浣垮湪闂宸茬粡瑙ｅ喅涔嬪悗銆?BR> d.浣犳案榪滀篃涓嶈兘鑲畾浣犳湁浜嗕竴涓紜殑瀹氫箟錛屼絾鏄案榪滀笉瑕佹斁寮冨姹傚畠鐨勫姫鍔?BR>
]]>
1錛?縐熻祦澶фゼ鐨勫ぇ閮ㄥ垎鍔炲叕瀹ゅ湪宸ヤ綔鏃ョ殑鏃╀笂9 鐐瑰埌涓嬪崍5 鐐逛箣闂村姙鍏?BR>2錛?鍑犱箮鎵鏈変嬌鐢ㄥぇ妤肩殑浜轟滑閮戒笌閲戣瀺鐣屾湁鐫鏌愮鏂瑰紡鐨勮仈緋匯?BR>3錛?鎵鏈変綇鎴鋒瘮杈冨潎鍖鍦板垎甯冨湪澶фゼ鐨?3 灞傦紝鐢墊浜ら氫篃涓鏍楓?BR>4錛?鎴夸笢涓轟簡鎶婂墿浣欐埧闂寸鍑哄幓錛屽凡緇忓湪騫垮憡涓婂仛浜嗗ぇ閲忕殑鎶曡祫銆?BR>5錛?鍦ㄩ噾铻嶅尯榪欎釜灝侀棴鐨勫皬鍦堝瓙閲岋紝鎵鏈変笉濂界殑娑堟伅浼犳挱寰楀儚闂數涓鏍峰揩
浜?闂鐨勮В鍐?BR> 1) 紜畾闂鐨勬嫢鏈夎?涓嶅悓鐨勬嫢鏈夎呬細鏈変竴緋誨垪瀵瑰簲鐨勮В鍐蟲柟妗?BR> a.鐢墊浣跨敤鑰?BR> eg.淇悊鐢墊,闄愬埗榪涘叆澶фゼ鐨勪漢鏁?.....;
b.澶фゼ綆＄悊鍛?BR> eg.澧炲姞鎴跨錛屽彧闇瑕佹洿灝戠殑鎴垮灝卞彲浠ユ敮浠樻姷鎶艱捶嬈撅紙寤洪犲ぇ妤兼椂鎵鏀嚭鐨勶級,璁炬硶璇存湇瀹㈡埛錛屽憡璇変粬浠鍥犱負澶фゼ鏄竴涓瀬濂芥瀬鏂逛究鐨勫伐浣滃湴鐐癸紝鎵浠ユ墠浼氭湁澶фゼ鐩墠鐨勭數姊姸鍐?..
2) 瀵歸棶棰樿繘琛岃皟鐮?鎴垮甯屾湜灝藉揩璧板畬澶ч棬涓庡姙鍏涔嬮棿鐨勮窛紱?緇忛獙鍛婅瘔鎴戜滑,鏃㈢劧鐢墊鏃犳硶鎻愰?璺濈鏃犳硶緙╃煭,鍙互璁╀粬鍦ㄨ蛋榪欐璺椂'蹇欑'璧鋒潵,浜庢槸鍦ㄨ蛋寤婇噷绔嬭搗闀滃瓙,榪欐牱璁稿浜轟細鍋滀笅鏉ョ湅鐪嬭嚜宸變粖澶╁竻涓嶅竻,榪欐牱鐢墊灝變笉浼氭尋......鍚庡張鍙戠幇閮ㄥ垎鍛樺伐鐖卞湪闀滃瓙涓婃秱楦?瀵艱嚧闀滃瓙涓嶅対鍦?鏃㈢劧榪欐牱,鎴戠粰浣犵瑪,璁╂墍鏈変漢閮借兘灞曠ず鑷繁鐨勬墠鍗?鍚屾牱鍙堣揪鍒頒簡涓婅堪鐩殑......
涓?鎬葷粨
姝ｅ搴忚█涓墍璇?闂鏄湡鏈涗笌浣撻獙涔嬮棿鐨勫樊鍒?宸埆鍑虹幇鍚?涔熷氨鏄棶棰樿鎻愬嚭;
a.鏈鍙よ佺殑鏂規硶:鎴戜笉綆?鎴戞病鐪嬪埌,鎴戝綋浠栦笉瀛樺湪,榪欎釜絳栫暐鏈夋椂浼氭湁鏁?BR> b.绔嬪嵆閽堝宸埆鎻愬嚭瑙ｅ喅鏂規
c.紜闂鐨勫璞?瀹氫箟闂鐨勬湰璐?
涓嬈″け璐ョ殑闂瑙ｅ喅妗堜緥:
鎴戝湪LY欏圭洰涓仛緗戜笂閲囪喘鏃?瀹㈡埛閽堝鎰忓悜琛ㄥ垪琛ㄦ彁鍑?nbsp; : 鎴戦渶瑕佸湪榪欐坊鍔犱竴涓寜閽椂,鎴戞兂閫氳繃鐐瑰嚮浠栫湅鍒板巻鍙蹭俊鎭?姝ゆ椂瀹㈠凡鎴鋒彁鍑虹殑瑙ｅ喅鏂規,鑰?FONT color=#0000ff>涓庡鎴瘋璁哄墠鎴戣寰楅棶棰樻槸瀹㈡埛鏃犳硶鐪嬪埌鍘嗗彶淇℃伅,鎴栬呰浠栨湡鏈涘鏁版嵁榪涜絳涢?褰撶劧涔熻榪欎篃涓嶆槸鏈緇堢殑闂鎵鍦?浣嗘槸鎴戞墍鑳界湅鍒版渶榪滅殑^_^.鐢變簬緋葷粺璁捐涓婄殑鍘熷洜,鎴戜簡瑙ｄ簡涓涓?鐪嬩技綆鍗曠殑娣誨姞涓涓寜閽?闇瑕佹敼鍔ㄧ殑涓滆タ姣旇緝澶?鎬諱箣闅?絳栫暐涓鎴戜笉綆?浼間箮涓嶈,瀹㈡埛鍥犱負涓浜涘墠鏈熺殑鍘熷洜,瀵歸」鐩殑婊℃剰紼嬪害涓嶉珮,鐜板湪棣栬瑙ｅ喅鐨勬槸鎻愰珮瀹㈡埛濂芥劅搴?鏃㈢劧瑕佸叧娉ㄨ繖涓棶棰?棣栧厛瑕佹憜鍑轟竴涓Н鏋佺殑濮挎?鎴戝拰浠栬闂宸叉斁鍏ラ棶棰樺垪琛?涓旀爣娉ㄤ負high,榪欐牱緇欎粬涓涓嵃璞?闂宸茬粡寰楀埌鍏蟲敞,浠栫殑鎰忚寰楀埌浜嗗簲鏈夌殑閲嶈(姹?,浠栨槸涓狶T,瑕佹槸涓狹M閭ｅ濂?鍝堝搱);鎴戜箣鍚庡拰浠栬璁?/FONT>榪欎釜闂,浠栬涓哄暐瑕佹坊榪欎釜鎸夐挳鍛?鍘熷洜鏄兂璁╂搷浣滀漢鍛樺叧娉ㄥ綋鍓嶆鍦ㄧ淮鎶ょ殑璁板綍,鍓旈櫎鍘嗗彶璁板綍鏈夊埄浜庤仛鐒﹀伐浣滈噸鐐?浜嬪疄涓婃垜騫舵病鏈夋帴瑙﹀埌鏈緇堢敤鎴?鎵浠ユ垜涔熸棤浠庡緱鐭ヤ粬浠槸鍚︽湁榪欎釜闇瑕?,鎴戞槑鐧戒簡,闂榪涗竴姝ユ樉鐜?鏄洜涓虹敤鎴鋒病鏈夊姙娉曞尯鍒嗗綋鍓嶈褰曠殑鐘舵?鎴戝綋鏃舵檿浜唍鎶?/FONT>),閽堝緋葷粺鐨勫疄鐜?鐜板湪宸叉湁涓涓姸鎬佸垪,濡傛灉鎴戞寜鐓х姸鎬佹帓搴?鎶婂綋鍓嶆湭閫氳繃瀹℃牳鐨勬剰鍚戣〃璁板綍鏄劇ず鍦ㄥ墠闈?浼間箮涔熻兘瑙ｅ喅闂,鎴戞兂鎻愬嚭榪欎釜瑙ｅ喅鏂規,鎴戣寰楁尯瀹岀編,鏃㈣В鍐充簡浠栫殑闂鍙堣В鍐充簡鎴戝疄鐜伴毦鐨勯棶棰?涓嶈繃.....浠栬榪欐牱鐨勮瘽鏈夊彲鑳芥湁涓欏墊樉紺?0鏉¤褰曚腑,鍓嶄節鏉℃槸鏈氳繃瀹℃牳鐨?鏈鍚庝竴鏉℃槸閫氳繃瀹℃牳鐨?瑙夊緱榪樻槸涓嶇埥,騫跺拰鎴戣:浣犺兘瑙ｅ喅鍚?涓嶈兘瑙ｅ喅灝辯畻浜?鎼炲緱鎴戝緢娌￠潰瀛?緇撳眬灝辨槸鍦ㄧ郴緇熶腑鍐欎簡涓浜?璇″紓'鐨勪唬鐮?瀹炵幇浜嗚瑕佹眰.
涔嬪悗涓鐩村湪鎯?鎾囬櫎緋葷粺璁捐鐨勭己闄峰,涓轟粈涔堟病鑳藉弻璧㈢殑瑙ｅ喅榪欎釜闂,璞′功涓偅鏍鋒湁鍒涢犳?緇撹鏄?nbsp;
鎴戣繕寰堝急,榪樺緱緇х畫鐪嬭繖鏈功,^_^!
]]>
a.鎶撲綇闂鐨勬牴婧?eg.瀹㈡埛鎻愬嚭鏌愪釜鍙樻洿鍚?棣栧厛鎯沖埌鐨勬槸浠栦負浠涔堜細鎻愬嚭鍙樻洿,鍐嶆牴鎹繖涓師鍥犱笌涔嬪晢瀹氳В鍐蟲柟妗?BR> b.绔欏湪鍚勪釜瑙掑害鐪嬪緟闂,鏂硅兘鐭ラ亾闂鐨勬牴鏈?鍗充嬌鎵懼埌瑙ｅ喅鏂規鍚?浠嶉渶瑕佸鍏朵笉鏂鏍?淇濇寔璀︽儠蹇?BR> c.鍖哄垎闂鐨勫畾涔夊拰瑙ｅ喅鏂規;eg.瀹㈡埛鎻愬嚭鐨勫線寰鏄В鍐蟲柟妗堣屼笉鏄鑷寸殑鏍規簮
d.姘歌繙涓嶈鑲畾鑷繁宸茬粡瑙ｅ喅闂浜?鍗充嬌everything goes well!(^_^,榪欎笉鏄姌鑵捐嚜宸卞悧)
3.闂鐨勫畾涔?闂鍏跺疄灝辨槸浣犵殑鏈熸湜鍜屼綘鐨勬劅鍙椾箣闂寸殑宸埆錛岃屼笖涓嶇鐪嬩笂鍘誨浣曪紝浜轟滑寰堝皯鐭ラ亾浠栦滑瑕佷粈涔?.鐩村埌..浣犵粰浜嗕粬浠墍闇瑕佺殑涓滆タ.
]]>