oauth2
http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-5.1
For example:
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.2.2
http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.1.4
Represents the scheme used for decoding access tokens from a given requests.
Represents the authorization source that issued the access token.
Paths for authorization and token access
A composition of components which respond to authorization requests.
A composition of components which respond to authorization requests.
This trait provides default implementations of Oauth Flows. To override these,
simply override a target Flows callback methods
Represents Bearer auth encoded in a header.
Represents Bearer auth encoded in a header. see also http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-14
TODO: What about the designation of this client? WebApp, Native etc...
TODO: What about the designation of this client? WebApp, Native etc... these are mandated parts of client registration as the designtation infers the grant type.
When registering a client, the client developer:
- Specifies the client type as described in Section 2.1, - Provides its client redirection URIs as described in Section 3.1.2, and - Includes any other information required by the authorization server (e.g. application name, website, description, logo image, the acceptance of legal terms).
Locate a registered client.
Locate a registered client. This could be from anywhere but assuming its a database or other persistance store then the clientId should be used as the key.
http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.1.2.1
For example, the authorization server redirects the user-agent by sending the following HTTP response:
HTTP/1.1 302 Found Location: https://client.example.com/cb?error=access_denied&state=xyz
Or, another example:
HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "error":"invalid_request" }
Defines a composition of oauth flows.
Defines a composition of oauth flows. Services may opt out of flows mixing in NoAuthCodes, NoTokens, NoPasswords, NoClientCredentials, or NoRefreshing
A type of request where response type is ambiguous
Represents MAC auth.
http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.1.2 For example, the authorization server redirects the user-agent by sending the following HTTP response:
HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
Configured Authorization server module
After your application has obtained an access token, your app can use it to access APIs by including it in either an access_token query parameter or an Authorization: Beader header.
After your application has obtained an access token, your app can use it to access APIs by including it in either an access_token query parameter or an Authorization: Beader header.
To call API using HTTP header.
GET /api/1/feeds.js HTTP/1.1 Host: www.example.com Authorization: Bearer vF9dft4qmT
Provides OAuth2 protection implementation.
Provides OAuth2 protection implementation.
Extend this trait to customize query string oauth_token, etc.
Represents Bearer auth encoded in query params.
Represents Bearer auth encoded in query params. ses also http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-14
Encapsulates information sent by a Client Authorization request that may need to be repeated after authentication, account creation, or other container behavior before an authorization request can be processed
A ResourceOwner belongs to a Service
Request responses a Service must implement to complete OAuth flows
The access token provides an abstraction layer, replacing different authorization constructs (e.g.
The access token provides an abstraction layer, replacing different authorization constructs (e.g. username and password) with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.
Access tokens can have different formats, structures, and methods of utilization (e.g. cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications.
A hook for providing extension properties is provided as the extras
method which defaults to an empty map
The token store controls token-orientated operations.
The token store controls token-orientated operations. Specifically anything that needs to happen with a token is the responsibility of the incumbant TokenStore as typically it will require interacting with the some kind of storage
Customized parameter validation message
Extractor for a resource owner and the client they authorized, as well as the granted scope.
http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.1.3