Users connecting services to the MyAcademicID 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 | offline_access | Client authentication methods | PKCE | |
|---|---|---|---|---|
authorization_code | false | client_secret_basic and client_secret_post | false | |
authorization_code | false | client_secret_basic and client_secret_post | true | |
authorization_code | false | public | false | |
authorization_code | false | public | true | |
authorization_code and refresh_token | true | client_secret_basic and client_secret_post | false | |
authorization_code and refresh_token | true | client_secret_basic and client_secret_post | true | |
authorization_code and refresh_token | true | public | true | |
authorization_code and token-exchange | false | client_secret_basic and client_secret_post | false | |
authorization_code and token-exchange | false | client_secret_basic and client_secret_post | true | |
authorization_code and token-exchange | false | public | true | |
authorization_code and refresh_token and token-exchange | true | client_secret_basic and client_secret_post | false | |
authorization_code and refresh_token and token-exchange | true | public | true | |
implicit | false | public | false | |