With OpenID Connect, trust is established out-of-band, by supplying the Service Provider with a username and a secret. All the necessary technical information such as endpoints, supported algorithms and supported claims can be found at the .well-kown endpoint: https://oidc.surfconext.nl/.well-known/openid-configuration
SURFconext couples the SP and the IdP based on specific rules.
Note that SURFconext itself does not authenticate users: this is done by the connected Identity Providers.
<< picture >>
OpenID Connect authentication process in steps
Todo
The picture above is a schematic representation of the login flow of the SURFconext OpenID Connect proxy. To get a feeling of how things work in reality, you can play around with our playground: https://authz-playground.connect.surfconext.nl.
User accesses a Service Provider (Relying Party) and clicks "login via SURFconext"
Client (SP) generates OpenID Connect Authorize request and
Client (SP) redirects Redirects user to the OpenID Connect Authorization endpoint
OpenID Connect server receives request and prepares a SAML redirect to authenticate the user
WAYF: User selects institution on WAYF
IdP parses request, authenticates user
IdP redirects back to SURFconext with SAML response
In order to determine where to send the user for authentication, SURFconext shows the user a "Where Are You From?" (WAYF) page with all Identity Providers that have access to the service. The user chooses the institution that is his Identity Provider.
- The IdP authenticates the user, usually by asking to enter his credentials. After validating,
the IdP generates a SAML response and redirects the user back to SURFconext with a response message, saying that the user is authenticated. The message also contains the attributes from the user.
SURFconext validates the response message and if OK makes some alterations, e.g. rewriting the user's identifier and adding or modifying attributes and sends the SURFconext sends a SAML response to the OpenID Connect gateway. According to the attribute release policy applied, SURFconext determines the attributes that are allowed through to the Service Provider.
The OpenID connect gateway verifies the reponseresponse, generates a code, and redirects the user to the Client (SP) with the code
The Client (SP) receives the authorization code
The Client (SP) prepares a backchannel request to the exchange the token for an access and ID token
The OpenID connect gateway receives the token , and checks the validity
The OpenID connect gateway generates an access and id ID token
- The access and ID token are posted to the redirect URL of the Client (SP)
The picture above shows what a client could do with an accestoken: The accesstoken
<< picture >>
The Client (SP) now has 2 tokens; an ID token which contains a pseudonymous identifier and an access token that can be used to verify it can retrieve information from resource servers on behalf of the user. The picture above sketches this process. - The Client (SP) has received the access token in the authentication flow. It uses the token to retrieve information from a resource server. The OIDC OpenID Connect server itself has a special resource server, called the userinfo endpoint. This endpoint van can supply user claims (attributes).
- The resource server receives the access token, and prepares a request to the introspect endpoint of the OIDC OpenID Connect server, where it checks the validity of the token
- The introspect endpoint verifies the validity of the access token, and returns some info about the user, allowing the resource server toidentify to identify the user
- The resource server receives the information on the user
- The resource server retrieves the requested user information and generates a response
- The client Client (SP) receives the information about the user (claims, group membership, other resources)
...