Registreren

Pages
- Building your application
- Advanced functions
  - Deployment
  - Branches
  - Security
  - Mail & spam
  - Standard urls
  - REST API
  - SSO
    - OIDC as client
    - OIDC as Identity provider
  - Social media
  - HTML Editor
- Hosting
- Miscellaneous

OIDC as client

What is OIDC?

OpenID Connect is a secure, standardized protocol for authentication between platforms/applications. A Client application uses an Identity Provider (application) to authenticate users and retrieve user info. This user info can then be used in the Client application. It is a way to implement Single Sign On functionality.

The benefit of using this protocol has to do with the separation of concerns, while also having a single source of truth for user info if there are multiple Client applications. The concern for secure authentication using a username, password, and perhaps multi factor authentication, remains with the Identity Provider.

A well known example of an Identity provider is Microsoft Azure. But a Crossmarx Application can also be set up as an Identity Provider.

Setting up the Client

If you want to use your application as an OIDC Client, you will have to make sure that you have contacted Crossmarx first to activate this feature.

Then you need to make sure that the account system in your application is configured. Your application needs:

a usergroup with the setting "Allow account operations in script" set to 'true';
a class that can hold user information, with at least one field of datatype 'email'.

Then on the tab "Other settings" of the user class, the setting 'Email field for account' needs to be set to the email field of the current class.

In the Backstage you can add a Social Login Setting. From the main menu it can be found through the following path: Definition -> Configuration (for all branches) -> Social login settings.

The configuration should be as follows:

Type: "OIDC client"
Label: the text that is shown on the login button.
Domain name (optional): If you want to bind this authentication option to a specific domain name. The login button will only appear if that domain is used.
Client id: a unique id provided by the Identity Provider.
Secret key: a unique secret key provided by the Identity Provider.
Authorize endpoint: the endpoint for the authorize call provided by the Identity Provider.
Token endpoint: the endpoint for the token call provided by the Identity Provider.
JWKS endpoint: the endpoint for the certificates call provided by the Identity Provider.
User class: the user class where the user account system is active on. Any (new) user(s) will be stored in the Client application at this class.
User group: which user group the (new) users will have by default. This can be changed automatically by providing the value from the identity provider using a custom Claim and then processing that value in the post processing script.
New account succeeded url (optional): a URL in your application where the user should be redirected to after a new account creation.
Claims (optional): custom information you can exchange with the Identity Provider.
Post process script (optional): a script in which you can extract the custom data from the claims.

Claims

Claims can be used to exchange custom information between the Identity Provider and Client. This has to be coordinated with the Identity Provider.

In the Post process script field you can script the retrieval of the custom data. Furthermore, it is also possible to immediately perform extra actions (perhaps based upon the custom data). For example, it is possible to change the user group depending on the value of a certain claim.

It is important that the claim keys are exactly the same on both the Identity Provider and Client side.