Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The full specification of the OAuth 2.0 authorization framework can be found at: http://tools.ietf.org/html/rfc6749. In the following this is referred to as "the specification". Any features in this document that do not follow the specification are marked "non-standard". 

Keycloack is implementing all four authorization grant types Archie is implementing three of the four authorization methods or 'flows' described in the specification:

  1. Authorization Code Grant flow (section 4.1 of the specification), informally known as the server-side flow.
  2. Implicit Grant flow (section 4.2 of the specification), informally known as the client-side flow.
  3. Resource Owner Password Credentials (section 4.3 of the specification).

  4. Client Credentials Grant (section 4.4 of the specification), also known as the client credentials flow.

...

  1. .

...

  1.  


The aim of each supported flow is for the client to obtain an access token that can be used in subsequent API calls to read and/or modify resources in Archie or Review DB in the context of the end user. This is done in a way (using HTTP redirects) where the end user never has to enter his or her Cochrane Account password into the client application but only on the common Archie SSO login page.

OAuth 2.0 can also be used for single sign on, i.e. the ability for the end user to log into the client using his or her Cochrane Account, by utilising the authentication part of the OAuth flow only, and not using the access token for further API calls. 

...

Before a client can use the system it must be registered with Archie Keycloack with the following information:

...

In addition, for the client credentials flow, an Archie Keycloack user must be associated with the client. The access token obtained with this flow will be associated with this user and the user's permissions.

...

  • confidential client is one that is capable of keeping its client credentials secret and the access token hidden from the end user. This typically means that a server has to be involved where the access token can be stored in a user session object. A confidential client is using the server-side flow to obtain the access token server-to-server without involving the browser, and in this process it authenticates itself to Archie using its client ID and client secret. Since this is the most secure type of client it has more privileges than a public client, e.g. the ability to refresh access tokens that are about to expire. Confidential clients may also use the client credentials flow to obtain an access token server-to-server without involving an end user.
  • The typical example of a public client is a pure HTML5/JavaScript app. Since the source code and memory can be inspected by the end user in the browser this type of client is not capable of keeping the access token hidden from the end user. And since the client secret would be visible in the source code there's no point in assigning a secret to a public client. A public client is using the client-side flow to obtain short lived (e.g. 4 hours) access tokens. 
Note
titleCheck if true?
The registration of redirect URIs is vital for the security of the system, and

...

Keycloack only allows complete URIs (no wildcards) to be registered. However, a client is allowed to register multiple URIs.

Endpoints

All endpoints require a secure connection (HTTPS). If plain HTTP is used an error status code 403 (forbidden) is returned.

...