-
Notifications
You must be signed in to change notification settings - Fork 1
Home
This framework contains three different classes for working with three different aspects of OAuth 2.0:
- Creating an OAuth 2.0 authentication server to allow users of your application/website to approve external access for other applications/websites to access their resources.
- Protecting your existing API with an OAuth resource server.
- Allowing users to sign in to your application/webiste with major OAuth 2.0 providers which currently include:
- Bloo.ie
- Foursquare
- Github
- Mailchimp
- Mail.ru
- Paypal
- Soundcloud
- Vkontakte
- Windows Live
- Yandex
This documentation uses the following terms:
-
resource owner
An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as auser
. -
resource server
The server hosting the protected resources, capable of accepting and responding to requests for protected resources using access tokens. -
client
An application making protected resource requests on behalf of the resource owner and with its authorisation. The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices). -
authorisation server
The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorisation.
+--------+ +---------------+
| |--(A)- authorisation Request ->| Resource |
| | | Owner |
| |<-(B)-- authorisation Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- authorisation Grant -->| authorisation |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
The abstract OAuth 2.0 flow illustrated in Figure 1 describes the interaction between the four roles and includes the following steps:
(A) The client requests authorisation from the resource owner. The authorisation request can be made directly to the resource owner (as shown), or preferably indirectly via the authorisation server as an intermediary.
(B) The client receives an authorisation grant, which is a credential representing the resource owner's authorisation, expressed using one of four grant types defined in this specification or using an extension grant type. The authorisation grant type depends on the method used by the client to request authorisation and the types supported by the authorisation server.
(C) The client requests an access token by authenticating with the authorisation server and presenting the authorisation grant.
(D) The authorisation server authenticates the client and validates the authorisation grant, and if valid issues an access token.
(E) The client requests the protected resource from the resource server and authenticates by presenting the access token.
(F) The resource server validates the access token, and if valid, serves the request.