...
| 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 authentification 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. |
Depending on the use-case, oAuth2 provides four multiple authentication and administration methods, or called grant types, which are given in the following table. Hereby, an application, called client, can request an access token for a specific scope which isset.
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. |
|
| ||||||||||||||||||
| Client Credentials | Given , a client is owner of a set of resources, it can request a corresponding access token itself. |
| Request: Response: | ||||||||||||||||||
| 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. |
| Request: Response: | ||||||||||||||||||
| Refresh Token | Access tokens expire after a certain period. To expand a valid access token a client can request a new access token using a refresh token obtained with the old one. |
| Request: Response: |
* The redirect_uri is validated by oAuth2 due open redirection vulnerabilities. (see previous section)
Each method uses individual parameters which are described as follows:
In some scenarios, e.g. with the grant type "Authorization Code", a client probabily would like to verify its received access code. 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 seperate URL:
| Method | Description | Parameter | Example | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Verify Access Token | Allows a client to verify an access token not directly requested from the oAuth2 server. |
|
|
The following examples show concrete use-cases where the session login and oAuth2 mechanisms are used within the Flarecast infrastructure.
InfraViewer
Request Description Response POST /login The end-user performs a login with his username and password. The service verifies the user's authentication and, if successful, requests an access token from the oAuth2 server (using the grant type 'password). The end-user is then redirected to his original page either with or without a valid session ID and access token cookie. Depending on those cookies the service can give access to restricted operations, using the session ID, or can request secured ressources, using the user's access token. GET /ressource_1 The end-user requests a non-secured resource from the service. The service response with a normal JSON object. POST /ressource_1 The end-user requests a secured resource from the service. The service
Technical Details
flask-login, flask-oauthlib
...