Web Blog_blogentry_140615_1


OAuth 2.0 Authorization#

Here we show the Authorization Code Grant Type which would typically be used for WEB Server type applications.

Some basic conditions must exist in advance:

1) The Resource Owner (user) accesses the OAuth Client (The Photo application).

2) The OAuth Client constructs the Authorization Request as a URI, adding the following parameters:

    • response_type - REQUIRED Value MUST be set to "code".
    • client_id - REQUIRED The client identifier
    • redirect_uri - OPTIONAL as it may be registered with Authorization Server in advance.
    • scope - OPTIONAL The "Desired" scope of the access request
    • state - RECOMMENDED An opaque value used by the client to maintain state between the request and callback.

3) The Resource Owner (user) is redirected by the OAuth Client (The Photo application) with the Authorization Request to the Authorization Endpoint on the Authorization Server.

4) The Resource Owner (user) Authenticates the Authorization Server.

5) The Resource Owner (user) is then redirected to the redirect_uri of the OAuth Client (The Photo application).

6) When the OAuth Client (The Photo application) redirect_uri is accessed, the OAuth Client (The Photo application) connects directly to the Authorization Server and creates Access Token Request which includes:

7) If the Authorization Server can accept these values, the Authorization Server sends back an Access Token Response which includes:

8) The OAuth Client (The Photo application) can now use the Access Token to request resources from the Resource Server. The Access Token serves as both:

There is no OpenID Connect involved with this operation. This is all part of OAuth 2.0 Protocol

More Information#

There might be more information for this subject on one of the following: ...nobody