Page History

Users connecting services to the eduTEAMS Service using OpenID Connect (OIDC) will need to choose which Grants their services need. This page and the following table present guidance for the recommended and supported configurations.

References to the specifications:

For more information on "Authorization Code Flow", "Refresh Token" and "Implicit Flow" read the OpenID Connect Core 1.0 document.
For more information on "Token Exchange" read the RFC8693 — OAuth 2.0 Token Exchange document.
The Implicit Flow is discouraged due to security concerns. Instead, consider the Authorization Code Flow with PKCE. For more information read the OAuth 2.0 Security Best Current Practice document, especially section "2.1.2. Implicit Grant".

A service will typically act as a confidential client and will authenticate with its client-id and client-secret using client_secret_basic or client_secret_post.

Non-confidential clients are marked as "public". These services are usually web-based applications without a backend. According to best practices these clients should support PKCE.

PKCE stands for "Proof Key for Code Exchange". For more information read the RFC7636 — Proof Key for Code Exchange by OAuth Public Clients document.
Using PKCE is recommended for all grants based on the Authorization Code Flow. For more information read the OAuth 2.0 Security Best Current Practice document, especially section "2.1.1. Authorization Code Grant".

Notice that multiple grants can be selected. However, requesting all Grants is not a valid request (it cannot work).

It is common to request the authorization_code grant alone, or along with the refresh_token grant. This is normal and this is what most clients should look like.
Some clients will request the authorization_code grant and they will be public clients (ie, web-applications). We encourage those clients to support PKCE.

The device-code grant is not common. Only public clients will request this grant.

The token-exchange grant should only be used by advanced clients. This is expected to be requested rarely.
This grant will be requested along with the authorization_code grant and maybe the refresh_token grant.
These clients will not be public clients.

Requesting the implicit grant should be very-very-very rare. If implicit is used then no other grant type should be used.

Grants

_types_supportedresponse_types

	offline_access

clienth_authn_methodpkce_essential

Client authentication methods	PKCE
`authorization_code`

code

false		client_secret_basic and client_secret_post	false
`authorization_code`

code

false		client_secret_basic and client_secret_post	true
`authorization_`

code

`code`	false		public	false
`authorization_code`

code

false		public	true
`authorization_code and refresh_token`

code

	true		client_secret_basic and client_secret_post	false
`authorization_code and refresh_token`

code

	true		client_secret_basic and client_secret_post	true
`authorization_code and refresh_token`

code

	true		public	true
`authorization_code and token-exchange`

code

false		client_secret_basic and client_secret_post	false
`authorization_code and token-exchange`

code

false		client_secret_basic and client_secret_post	true
`authorization_code and token-exchange`

code

false		public	true
`authorization_code and refresh_token and token-exchange`

code

true		client_secret_basic and client_secret_post	false
`authorization_code and refresh_token and token-exchange`

code

true

public

true

implicitid_token token


`device_code`	false	public	false
`device_code and refresh_token`	true	public	false
`implicit`	false	public	false

Page tree

Versions Compared

Old Version 2

New Version Current

Key