Page History

...

Authentification Mechanism	Used By	Description	Protection Level
Session Login	End-Users	Restricts the permission on specific routes by validating the session ID of a request. If an end-user does not hold an approved session ID he has to authenticate himself over a login page with a username and password. If the login was successful, the end-user's session ID becomes active.	Web pages with restricted functions.
oAuth2 (RFC6749)	Applications	Restricts the permission on specific routes by validating an access token within the request's header. If an application does not hold an active access token it has to request a token from the oAuth2 authentication authorisation server. Each route is tagged with one or multiple 'scopes' which groups protected resources. An access token is related with a list of scopes and only provides access to correspondingly tagged resources.	Restricted REST resources.

...

Method

Description

Parameter

Example

Authorization Code

An end-user authorizes a specific client for a set of resources. The application can then request the corresponding access token provided by the end-user.

Column

width	250px

scope	list of strings
code	grant's unlock code
client_id	client's ID
redirect_uri	client's URL*

Column

width	410px

Request:
http://workflowmgr:8003/oauth/token
    ?grant_type=authorization_code
    &scope=read
    &code=1234
    &client_id=1234
    &redirect_uri=http://localhost:8002/ui

Response:
{
    "token_type": "Bearer",
    "version": "1.0.0",
    "access_token": "LLL7SFMWkE6BcNc6M4dXHQXJ3UINTz",
    "scope": "read",
    "expires_in": 86400,
    "refresh_token": "uC5FRcq1MsITDfMb1fQlPLQO7RhuxH"
}

Client Credentials

Given a client is owner of a set of resources, it can request a corresponding access token itself.

scope	list of strings
client_id	client's ID
client_secret	client's authentication code

Request:
http://workflowmgr:8003/oauth/token
    ?grant_type=client_credentials
    &scope=read
    &client_id=1234
    &client_secret=abcd

Response:
{
    "access_token": "wCPvIbuZoVp589eIczfmkNI1a8i5Ym",
    "token_type": "Bearer",
    "version": "1.0.0",
    "expires_in": 86400,
    "scope": "read"
}

Password

Clients are grouped into public and confidential clients. Hereby, a 'confidential' clients is allowed to request an access token in the name of an end-user.

scope	list of strings
client_id	client's ID
username	end-user's name
password	end-user's password

Request:
http://workflowmgr:8003/oauth/token
    ?grant_type=password
    &scope=read
    &client_id=1234
    &username=TestUser1
    &password=1234

Response:
{
    "token_type": "Bearer",
    "version": "1.0.0",
    "access_token": "zOJ5avH29S1gALoT2ogcjdpelR2HSF",
    "scope": "read",
    "expires_in": 86400,
    "refresh_token": "DGdSeoxPJDRFH4ZXzQwCJ6xZDX6F26"
}

Refresh Token

Access tokens expire after a certain period. To expand a valid access token a the client can request a new access token one using a refresh token obtained with the old onecorresponding refresh tokent.

scope	list of strings
client_id	client's ID
refresh_token	valid refresh token

Request:
http://workflowmgr:8003/oauth/token
    ?grant_type=refresh_token
    &scope=read
    &client_id=1234
    &refresh_token=DGdSeoxPJDRFH4ZXzQwCJ6xZDX6F26

Response:
{
    "token_type": "Bearer",
    "version": "1.0.0",
    "access_token": "OWLwWDpL2QDWKAHN8qWC7eBwqjKjs9",
    "scope": "read",
    "expires_in": 86400,
    "refresh_token": "IAFzNvlB7bAcU3TUZpdJxxkLEf8Kbv"
}

...

In some scenarios, e.g. with the grant type "Authorization Code", a client probably would like to verify its received access codetoken. As the RFC6749 for oAuth2 does not define such a scenario we adapted a common implementation, e.g. used by Google and Amazon, which provides a separate URL:

...

The central entity is the user which, by assumption, owns resources he grants access to. A client can then define reliable clients and administrate there grant as well as bearer (access) tokens. This workflow however is not defined by the above database schema nor oAuth2. Flarecast do not provide corresponding functionalities for managing users at the moment, so each user has to be manually added to the database. Furthermore, a fine-grained user management system may add some user roles which could then be mapped to specific scopes. An example may look likeis given by the following table:

User Role	Resource Scope	Example
Reader	read	Access to protected routes for querying configurations of prediction algorithms.
Writer	write	Access to protected routes for adding prediction data to existing predictions.
Moderator	read, write	Full (read and write) access to the prediction service.
Administrator	read, write, execute	Full access to the workflow management service, including protected routes for running and stopping Docker containers.

Space shortcuts

Page tree

Versions Compared

Old Version 23

New Version Current

Key