Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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 .

  1. User clicks "login via SURFconext"

  2. Client (SP) generates OpenID Connect Authorize request

  3. Client (SP) redirects user to the OpenID Connect Authorization endpoint

  4. OpenID Connect server receives request and prepares a SAML redirect

  5. WAYF: User selects institution on WAYF

  6. IdP parses request, authenticates user

  7. IdP redirects back to SURFconext with SAML response

  8. SURFconext sends a SAML response to the OpenID Connect gateway

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

  10. The Client (SP) receives the code

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

  12. The OpenID connect gateway receives the token, 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)


    The picture above shows what a client could do with an accestoken: The accesstoken can be used to verify it can retrieve information on behalf of the user

  15. The SP has received the access token in the authentication flow. It uses the token to retrieve information from a resource server. The OIDC server itself has a special resource server, called the userinfo endpoint. This endpoint van supply user claims (attributes)
  16. The resource server receives the access token, and prepares a request to the introspect endpoint of the OIDC 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 toidentify 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)



 

 

 

 

  • No labels