Basics Of Auth2.0 & Authorization Framework.

1.Background: The OAuth 2.0 authorization framework enables application to obtain limited access to an HTTP service. Access to protected resources is granted by issuing access tokens to clients to access HTTP service. Rather than the client directly authenticating to the API using credentials, or the credentials of a user, OAuth enables the client to authenticate by presenting a previously obtained token. The token represents (or contains) a set of attributes with user and client details . These tokens present less of a security and privacy risk than using secrets /passwords directly on the API call.

In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

2.Roles .

An OAuth 2.0 flow has the following role:

• Resource Owner: An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an
  end-user..
• Resource Server: Server hosting the protected resources. This is the API you want to access.
• Client: An application making protected resource requests on behalf of the
  resource owner and with its authorization. The term “client” does
  not imply any particular implementation characteristics (e.g.,
  whether the application executes on a server, a desktop, or other
  devices)
• Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

3.How to get access token & making requests to protected resource.

+--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

interaction between the four roles and includes the following steps:

(A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner or preferably indirectly via the authorization server as an intermediary.

(B) The client receives an authorization grant, which is a credential representing the resource owner’s authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.

(C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant.

(D) The authorization server authenticates the client and validates the authorization 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.

4. Grant types used to get access token: An authorization grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token.

4.1 Authorization Code: This flow is used by web application executing on a web server or native mobile apps in user device.

4.2 Implicit: The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly. The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token).

4.3 Resource Owner Password Credentials: The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token.

4.4 Client Credentials: The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.

5.AccessToken: Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token — a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

6.Refresh Token: Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).