User Tools

Site Tools


OAuth Log in Authorization

AOuth is a much used authentication protocol used for third party authorization. Proto uses OAuth for, for example the Android and iOS apps. Below you can find some detailed information about how to use OAuth with the Proto site.

The Proto site uses OAuth 2.0 with a three-legged flow.

Consumer Details

When working with OAuth, you will need consumer details. You can get this at one of the sysadmins. You will then get the following credentials:

  • Consumer ID
  • Consumer Secret
  • Callback URI

You use these credentials to identify the application.

Authentication Flow

The Proto site uses an Authorization Code Grant Flow, according to RFC6749 this flow is as follows:

   | Resource |
   |   Owner  |
   |          |
   +----|-----+          Client Identifier      +---------------+
   |         -+----(A)-- & Redirection URI ---->|               |
   |  User-   |                                 | Authorization |
   |  Agent  -+----(B)-- User authenticates --->|     Server    |
   |          |                                 |               |
   |         -+----(C)-- Authorization Code ---<|               |
   +-|----|---+                                 +---------------+
     |    |                                         ^      v
    (A)  (C)                                        |      |
     |    |                                         |      |
     ^    v                                         |      |
   +---------+                                      |      |
   |         |>---(D)-- Authorization Code ---------'      |
   |  Client |          & Redirection URI                  |
   |         |                                             |
   |         |<---(E)----- Access Token -------------------'
   +---------+       (w/ Optional Refresh Token)
  1. [B] In this web view the browser will display a login page for the Proto site. Here the user can fill in their Credentials. The Proto site then asks the user to give permission to the application to access their information.
  2. [C] When the Credentials filled in are correct and the use gives permission, the browser does a callback to the provided callback URI, with the condition that this is the same as the callback URI that the Authorization Server is familiar with. the callback URI is structured as follows: callback-URI?code=[authorization-code] where [authorization-code] is the Authorization code that the Authorization Server has generated.
  3. [D] In the background the Client can then use the Authorization code to request a token from the Authorization server. More information about this request in the section about the token request.
  4. [E] The server will then return an Access_Token, Refresh_Token and an expires_in value indicating how long the token is valid.

Token Request

The Token Request is a POST request to the following endpoint: “” with the following Headers:

headers = [“content-type” : “application/json”]

and the following body:

parameters = [

“grant_type” : “authorization_code”,

“code” : [authorization_code],

“redirect_uri” : [callback_URI],

“client_id” : [consumer_ID],

“client_secret” : [consuemr_secret] ]

The response of the server will be in json, and comprises of an access token, refresh token and an “expires_in” value

Token Refresh Request

As stated before, with the token, you will get a value for “expires_in”, which is the amount of seconds your access token will be valid for. after it is not valid anymore, the server will respond with a Session expired or Invalid response error. You can then use the refresh_token to request a new Access token from the Authorization server.


When performing a request to the API, be sure to include the access token in the header of the request. Because the token is a Bearer token, put the word Bearer in front of the token in the header.

documentation about the existing endpoints can be found here

ict/oauth.txt · Last modified: 2019/03/31 14:43 by h.bierma