...

Note that SURFconext itself does not authenticate users: this is done by the connected Identity Providers.

<< picture >>Image Added

OpenID Connect authentication process in steps

...

1. User accesses a Service Provider (Relying Party) and clicks "login via SURFconext"

2. Client (SP) generates OpenID Connect Authorize request and

3. Redirects user to the OpenID Connect Authorization endpoint

4. OpenID Connect server receives request and prepares a SAML redirect to authenticate the user

5. 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.

6. The IdP authenticates the user, usually by asking to enter his credentials. After validating,

7. 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.

8. 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 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.

9. The OpenID connect gateway verifies the response, generates a code, and redirects the user to the Client (SP) with the code

10. The Client (SP) receives the authorization code

11. The Client (SP) prepares a backchannel request to exchange the token for an access and ID token

12. The OpenID connect gateway receives the token and checks the validity

13. The OpenID connect gateway generates an access and ID token

14. The access and ID token are posted to the redirect URL of the Client (SP)
    << picture >>
    
    Image Added
    
    
    The Client (SP) now has 2 tokens; an ID token which contains a pseudonymous identifier and an access token that can be used to retrieve information from resource servers on behalf of the user. The picture above sketches this process.

     

15. The Client (SP) has received the access token in the authentication flow. It uses the token to retrieve information from a resource server. The OpenID Connect server itself has a special resource server, called the userinfo endpoint. This endpoint can supply user claims (attributes).
16. The resource server receives the access token, and prepares a request to the introspect endpoint of the OpenID Connect server, where it checks the validity of the token
17. The introspect endpoint verifies the validity of the access token, and returns some info about the user, allowing the resource server to identify the user
18.  The resource server receives the information on the user
19.  The resource server retrieves the requested user information and generates a response
20. The Client (SP) receives the information about the user (claims, group membership, other resources)

...