Qeo Open Source Project Documentation : Implicit Grant

About Implicit Grant

In the Implicit Grant type of OAuth, the client immediately receives an access token that can be used to access the web resource. Once the token is expired, the user will need to log in again to have further access to the web resource. More details on the implicit grant flow can be found in Section 4.2 of RFC 6749.

High-Level Flow

Below is the flowchart for the Implicit Grant type of OAuth2.0: 

Tokens

The client immediately receives an access token that can be used to access the Rest API. Once this token expires, the user needs to authenticate itself before the client can access the Rest API again.

Detailed Flow

All applications follow the same basic pattern when accessing the Qeo Rest API using OAuth 2.0. At a high level, using OAuth 2.0 to access the Qeo Rest API consists of these general steps, the numbers between brackets corresponding with the steps of the OAuth 2 process in the diagram above: 

1. Register the application (done once) (refer to Step 1 below)
    
2. Obtain an access token from the OAuth 2 Authorization server:
   1. Token request to the server (1)
   2. User login and consent (2)
   3. Return of access token by the server (3)
      

Step 1: Register your Application

This needs to be done only once. All applications that want to access the Qeo Rest API must be registered first. Currently registering your application is done by email (partnersalliancesupport@technicolor.com). In addition to a contact person and email, you will have to provide us the following information about your application:

You will get your personal client_id that you can use inside your application:

Step 2: Obtain an Access code from the Oauth2 Authorization Server

Before your application can access the Qeo Rest API, it must obtain an access token that grants access to that API. A single access token may grant varying degrees of access to multiple APIs. 

To obtain an access token, the user needs to be redirected to the authorization endpoint of the Security Management Server. This URL will present the user with a default OpenID selection page. The exact URL of this endpoint can be discovered in the Qeo Root Resource of the server, under "oauth" > "authorization" > "href".

Your application must provide the following parameters:

In addition to the mandatory OAuth parameters, the authorization request can contain the OpenID selection parameter. If provided, the default OpenID selection page won't be displayed. Instead the user will directly be redirected to the selected OpenId provider.

The user will be redirected to a login page requesting the credentials of the user. Once the user has filled in his credentials, his browser will be redirected to the redirect_uri. The url where it is redirected to also gets a query string in its url containing an access token.

Step 3: Provide the Access Token to the Qeo Rest API

After your application has obtained an access token, it can access the Qeo Rest API by including it in an Authorization: Bearer HTTP header.

Example

A company named example.org wants to create their own web application for managing their Qeo Realms.

1. They must first send an email to partnersalliancesupport@technicolor.com with the following information:
   
   

   application_name: Example Qeo Web
   redirect_URI:  http://qeo.example.org

   
   This means that the Security Server will only redirect to URLs starting with http://qeo.example.org. For example http://qeo.example.org/index.php will do, but http://www.example.org/ will not.
   
   

2. After the application is approved they receive a mail from Technicolor, containing:
   
   

   client_id: 2Xc6zKMNu2R3nuK6DQfho6be2F4U6M3m
   client_secret: Nq397Y7n563r9ugp5m2O9LP3s01U8Dx8

3. Now they can start building their web application. The first step is to add a link to the authorization endpoint providing the necessary client_id and redirect_uri:
   
   

   <a href="https://my.qeo.org/qeo-rest-security/oauth/authorize?response_type=token&client_id=2Xc6zKMNu2R3nuK6DQfho6be2F4U6M3m&redirect_uri=http://qeo.example.org">Click here to login!</a>

4. When the user clicks this link the browser is redirected to a Google login page asking the user to login with his Google credentials. This information is NEVER given to the web application, which is the main advantage of using OpenID/OAuth2.0 for authentication. 

   
   If it is the first time that the user is logged in this application he is asked whether he wants to trust this application. If the user clicks Accept he is redirected to:

   http://qeo.example.org#access_token=2YotnFZFEjr1zCsicMWpAA&expires_in=3600

   On subsequent logins, this check is skipped since the application already has the trust information, and the user is immediately redirected to the above URL.
   
   

   The web application located at http://qeo.example.org will be able to fetch the GET parameters from the request and extract the access token.

    

5. Now the qeo.example.org application has an access_token that can be used for accessing the Qeo Rest API. For example if the application wants to display all Realms belonging to the user it will send a GET request containing the access_token in its header:

   GET /v1/realms HTTP/1.1
   Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
   Host: my.qeo.org