| Info |
|---|
Some features marked with (NEW) are only present in the new OIDC implementation. If you connected after 10/11/2019, or if you migrated to the new gateway you can use this feature. If the OIDC server endpoint starts with https://connect.test.surfconext.nl or https://connect.surfconext.nl you can use this feature |
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.
...
We strongly recommend you use the "code " flow for your application. If you have a client that is not able to keep a secret (e.g. a Mobile App, or a JavaScript client), using PKCE is required. This method is described below.
...
| flow | reponse_type parameter |
|---|---|
| Authorization Code | code |
| Implicit | id_token |
| Implicit | id_token token |
| Hybrid | code id_token |
| Hybrid | code token |
| Hybrid | code id_token token |
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 instanceexample, 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:
...
Currently, we only support the scope "openid". You can may use any of the other scopes as specified in the OpenID Connect specification (profile, email, address, phone) but these are silently ignored. You get will receive the claims you requested during the deployment in the SP dashboardDashboard.
Prompt = login
...
Adding the 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.
...