[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 浼?xì)琚噸瀹氬悜鍒?OAuth Server 鐧誨綍騫跺悓鎰忔巿鏉? 涔嬪悗鍐嶈繑鍥炰笟鍔＄郴緇? 涓氬姟緋葷粺閫氳繃 Authorization Code 鍦?OAuth Server 澶勮幏鍙栬闂渶緇?Resource Server 鐨?Access Token
Implicit 涓?Authorization Code 澶т綋綾諱技, 鍙槸灝戜簡鐢?Auhtorization Code 鑾峰彇 AccessToken 鐨勬楠?br />Resource Owner 鏂瑰紡鏄鎴風(fēng)▼搴忕煡閬撶敤鎴峰悕鍜屽瘑鐮? 璁よ瘉鏃惰繛鍚岃嚜韜殑 Client ID 鍜屽瘑鐮佷竴璧峰彂閫佸埌 OAuth Server, 姣斿 CF Java 瀹㈡埛绔氨鏄嬌鐢ㄨ繖縐嶆柟寮?br />Client Credentials 鏄?Client Application 鏈韓灝辯被浼間簬 Resource Owner
Implicit 涓?Authorization Code 澶т綋綾諱技, 鍙槸灝戜簡鐢?Auhtorization Code 鑾峰彇 AccessToken 鐨勬楠?br />Resource Owner 鏂瑰紡鏄鎴風(fēng)▼搴忕煡閬撶敤鎴峰悕鍜屽瘑鐮? 璁よ瘉鏃惰繛鍚岃嚜韜殑 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 鍚? 浼?xì)鎻惤C虹敤鎴鋒槸鍚﹀厑璁歌闂暟鎹?br /> d. OAuth Server 浣跨敤娉ㄥ唽鐨勯噸瀹氬悜 URL, 鐢ㄦ埛鍐嶆琚畾鍚戝埌瀹㈡埛绔簲鐢ㄧ▼搴? 姝ゆ椂 URL 浼?xì)鍖呭?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, 涓ょ綾誨瀷鐨勫尯鍒湪浜? 絎笁鏂規(guī)槸鍚﹀彲浠ラ氳繃鏌愮鏂瑰紡鑾峰彇璇ヤ俊鎭?
5. Client Profile
a. Web Application 鎸囪繍琛屽湪 Web 鏈嶅姟鍣ㄤ笂鐨?Web 搴旂敤, 瀹為檯鍦烘櫙涓? 榪樺彲鑳藉寘鍚鎴風(fēng)嫻忚鍣?nbsp;
b. User Agent 姣斿榪愯鍦ㄦ祻瑙堝櫒涓殑 JavaScript 搴旂敤
c. Native 姣斿妗岄潰搴旂敤鎴栬呯Щ鍔ㄦ墜鏈哄簲鐢?br />
6. OAuth 2.0 Authorization
a. 娉ㄥ唽鍒?OAuth 鏈嶅姟鍣? 涓鑸墽琛屼竴嬈? Client Application 浼?xì)鑾峰彇鍒嗛厤鐨?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 涔熶細(xì)琚紶閫掕繃鍘? 榪欐牱 Authorization Server 鍙互鐭ラ亾鍝釜搴旂敤 (Client Application) 璇曞浘璁塊棶鍙椾繚鎶よ祫婧?br /> b. 褰撶敤鎴鋒垚鍔熺櫥褰曞茍鎺堟潈璁塊棶鍚? OAuth Server 浼?xì)鋴社?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 絳変環(huán)浜? 鐢ㄦ埛 (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 鍚? 浼?xì)鎻惤C虹敤鎴鋒槸鍚﹀厑璁歌闂暟鎹?br /> d. OAuth Server 浣跨敤娉ㄥ唽鐨勯噸瀹氬悜 URL, 鐢ㄦ埛鍐嶆琚畾鍚戝埌瀹㈡埛绔簲鐢ㄧ▼搴? 姝ゆ椂 URL 浼?xì)鍖呭?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, 涓ょ綾誨瀷鐨勫尯鍒湪浜? 絎笁鏂規(guī)槸鍚﹀彲浠ラ氳繃鏌愮鏂瑰紡鑾峰彇璇ヤ俊鎭?
5. Client Profile
a. Web Application 鎸囪繍琛屽湪 Web 鏈嶅姟鍣ㄤ笂鐨?Web 搴旂敤, 瀹為檯鍦烘櫙涓? 榪樺彲鑳藉寘鍚鎴風(fēng)嫻忚鍣?nbsp;
b. User Agent 姣斿榪愯鍦ㄦ祻瑙堝櫒涓殑 JavaScript 搴旂敤
c. Native 姣斿妗岄潰搴旂敤鎴栬呯Щ鍔ㄦ墜鏈哄簲鐢?br />
6. OAuth 2.0 Authorization
a. 娉ㄥ唽鍒?OAuth 鏈嶅姟鍣? 涓鑸墽琛屼竴嬈? Client Application 浼?xì)鑾峰彇鍒嗛厤鐨?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 涔熶細(xì)琚紶閫掕繃鍘? 榪欐牱 Authorization Server 鍙互鐭ラ亾鍝釜搴旂敤 (Client Application) 璇曞浘璁塊棶鍙椾繚鎶よ祫婧?br /> b. 褰撶敤鎴鋒垚鍔熺櫥褰曞茍鎺堟潈璁塊棶鍚? OAuth Server 浼?xì)鋴社?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 絳変環(huán)浜? 鐢ㄦ埛 (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.
]]>