Using accounts in a web site with the Identity Provider

The platform provides a full-fledged Identity Provider based on the OpenID Connect standard.

This allows a web site to use the SSO and delegate to a number of user-centric features, such as:

  • sign-in
  • sign-up
  • password reset
  • universal account profile (including login, password, email updates)
  • session management
  • avatar upload
  • unique account for various website and apps

You can see the user interface in action by going to and using your account.

Please contact us if you need to use this component.

OpenID Connect in a nutshell

OpenID Connect (OIDC) is an open standard. It is an identity layer built on top of the OAuth 2.0 framework. It allows third-party applications (including apps and websites) to verify the identity of an end-user and to obtain user profile information. The aim is to federate all user-centric features to a single service that can be deployed to numerous apps and web sites or services.

OAuth 2.0 is dedicated to verifying machine to machine resource access and sharing, OpenID Connect on the other hand is about end-user authentication. Its purpose is to give you one login for multiple sites. Each time a user needs to log in a client website or app using OIDC, they are redirected to the Identity Provider where they log in, and then taken back to the website with a cryptographic token that the website can use to gain information about the user.

A simple explication of OIDC can be found in OpenID Connect Explained article and OpenID Connect FAQ.

OIDC supports three distinct integration flows that depend on the use case and service implementation:

  • Authorization code flow: for websites implemented with a backend web server
  • Implicit flow: for Single Page Apps and web sites implemented in scripted front-end languages (javascript)
  • Hybrid flow: mix of both previous flows. This can be used to distribute the authentication and identity of the user to both a front-end web site and back-end web server

Moreover the Identity Provider also supports:

  • OpenID Connect Discovery (at this allows to use the Identity Provider without configuring the client.
  • OpenID RP Initiated Logout: this allows the client website to initiate a logout to all the website a user can be connected to through the identity provider.
  • Authentication delegation to other identity provider, like Google, Apple, Steam, etc. This allows a user of those services to seamlessly sign-in (and sign-up) to a 3rd party website implementing the Identity Provider & SSO.

Authorization code flow

This flow is used by back-end services or native apps. This is the most used flow. It is triggered by using the response_type value: code id_token.

When the user wants to sign-in in the client website (Relying Party in the OpenID Connect naming), the RP will redirect it (through HTTP redirection) to the Identity Provider Authorization code endpoint where the user will be able to sign-in (or create an account).

Once the Identity Provider validates the user, this one is redirected back to the original site (at an URL that has been previously configured) along with an authorization code in the code request variable. The RP will now use this code to get access to the identity of the user, by submitting it to the Code Exchange endpoint. In turns, the RP will receive an id_token and an access_token. The id_token can be used as a session cookie to maintain a session state on the RP, and can also be used to get access to the user identity with the Identity endpoint.

Implicit flow

This flow is used by front-end applications like single page applications. It is triggered by using the response_type value: id_token token.

When the user wants to sign-in in the client site, the client site will redirect the user to the Implicit flow endpoint. Once the use signs in and the Identity Provider validates their credentials. The Identity Provider will redirect back the user to the original site (at a preconfigured URL) along with the id_token and an optional access_token in the fragment part of the url. Like for the Authentication flow, the id_token after being validated can later be exchanged to get the user identity information.

Hybrid flow

This flow can be used by front-end and back-end applications at the same time. It is triggered by using the response_type value: code id_token token.

This flows works like the Authorization code flow. The end-user is redirected by the RP to the Identity Provider at the Authorization Code endpoint. The Identity Provider will redirect the user back to the RP with an id_token and the authorization code parameters in the URL fragment allowing the front-end to get access to those information. The clients needs to validate those parameters.

Next, the client can send the authorization code to the RP, which will send it the Identity Provider Token endpoint. This will return the id_token to the RP.

This way, both the client part (browser front-end) and the web back-end will have access to the id_token and thus the user identity.

Integration into your website

To integrate OIDC, the best is to use an existing library. This is very dependent to the site, app technology or framework in use. For instance with PHP backends, we recommend using Socialconnect Auth, for NodeJS backends OpenID Client/

For regular back-end based website, the Authorization code Flow is the way to go. For front-end based site or Single Page Applications, the hybrid or implicit flow are recommended.

You’ll find a long list of OpenID Connect libraries in the following list:

Note that we also provide our own client-side front-end javascript implementation: SSO JS.

Before a client application or website can use the Identity Provider and SSO, you need to contact us. We will setup the Identity Provider to accept your app or website, and give you the needed client credentials to connect.

More information

To learn more about OpenID Connect: