This page describes all the OpenID Connect (OIDC) features supported by SURFconext. In addition to reading this page, you can also play around with our playground application. This application allows you to review all features and, for instance, have a closer look at headers and responses. All features are compliant with the OpenID Connect specification.
All OpenID Connect flows (code, implicit and hybrid) are supported by SURFconext.
response_type parameter during the authorisation request you can specify which flow to use. The following values are allowed:
Proof Key for Code Exchange (PKCE)
PKCE is a security extension for public clients, originally for OAuth2. It mitigates attacks where the authorization code on public clients can be intercepted, such as Mobile or Desktop Apps which use callback URLs. For example, a rogue app can hijack the redirect URL and then obtain the authorisation code. These public clients typically do not have a secret configured when they exchange the code for an
access_token at the token endpoint.
PKCE solves this problem as follows. When an authorisation request is made, the RP generates a secret, and for more security, a hash of that secret. Two additional parameters are used:
code_challenge=XXXXX: The hash of the secret that has been generated
code_challenge_method=S256: This can be either S256, meaning that the SHA-256 hash of the secret is given, or plain, meaning that the secret itself is transmitted.
The server then ensures the generated code and the supplied code_challenge are stored.
In the request to the token endpoint, the
code_verifier is added, which is the secret that has been generated. The OIDC server then checks whether the secret is the same as the one in the original authorisation request. If not, no
id_token are provided. This effectively binds the first authorisation request to the token request.
More information can be found in the specification: https://tools.ietf.org/html/rfc7636
Currently, we only support the scope openid. You may use any of the other scopes as specified in the OpenID Connect specification (profile, email, address, phone) but these are silently ignored. You will receive the claims you requested during the deployment in the SP Dashboard.
Prompt = login
prompt=login parameter to the authorisation request will attempt to disable Single Sign-On, by forcing the Identity Provider to show the login screen and let the user re-authenticate. Important: SURFconext does not enforce connected IdPs to support this parameter, which means not all IdPs support this.
Request adding claims to the id_token
SURFconext supports the
claims request parameter which allows RPs to have the claims in the
id_token instead of in the user-info endpoint. Important: our minimal disclosure policy regarding the release of claims/attributes dictates which claims you are allowed to receive. You will not receive any claims you request which you are not allowed to receive.
More info on claims can be found here.
There is currently no official support for refresh_tokens. Although the token endpoint provides a refresh token currently, you cannot use it to refresh an access token. If you need longer lived access tokens because that is required for your sessions, you can give your access tokens a larger lifetime. This can be done using the SP dashboard.
If you do need refresh tokens, please contact support for further information. We expect official support of refresh tokens in Q4 2020.