Authentication Clients

Authentication Clients

The Authentication Clients implement OpenID Connect client id. This is an advanced setting, it is rarely required to configure. These are created automatically for each web application. You might create these if you have 3rd party applications using Agilicus AnyX as a Single-Sign-On provider (see VTScada Single-Sign-On as an example), you might edit them if you wish to alter the default parameters of a single application.

Background

An OpenID Connect (OIDC) client_id is a unique identifier assigned to an application that wants to use OIDC for authentication and authorisation. Think of it like a username for your application when it talks to an OIDC provider (in this case Agilicus AnyX)

• Purpose: It tells the OIDC provider which application is requesting access. This allows the provider to apply the correct security policies, redirect users back to the right place after login, and more.
• Uniqueness: Each client application registered with an OIDC provider gets a unique client_id. This is crucial for security and proper functioning.
• Configuration: When you register your application with an OIDC provider, you’ll receive a client_id (along with other credentials like a client_secret in some cases). You’ll then configure your application to use this ID when making authentication requests.
• Usage: The client_id is included in authentication requests sent to the OIDC provider. It’s used to identify the application and retrieve the appropriate configuration details.

Setup

The below images show an example of a default created client id for a web application. The name is created with a unique trailer to allow it to work into a sub-org that might have a same-named application.

The fields are:

• Client ID: the OpenID Connect client-id. This must be unique within all of your orgs
• Application: this is a pull down, selecting which application in the system to tie to
• Secret: this string is used when configuring an OAUTH2 3-legged flow (see The OAuth 2.0 Authorization Framework) in which a backend, non-graphical component participates as well as a browser
• Allowed Organisations: This can be used to control, grossly, which org can use this Client ID (rather than relying solely on assigned permissions). Valid values include: “Here Only”, “Here and Down”, “Any”, “<this org name>”, “<This org sub name>”.
• Multi-Factor. This is an alternate way of assigning multi-factor “when”. Valid values include: “Always”, “User preference”, “Trust upstream”
• Single Sign On Preference: This allows controlling whether a user can use ‘cached’ credentials (e.g. sign-in once for all apps, or, be forced to sign-in to each). Valid values include “User preference”, and “Never”.
• Redirects. If you add applications outside the scope of the Agilicus AnyX platform, you may need to configure a redirect URI that is specific to it.
• Authentication Attributes. This can be used to set fields that will appear in the ID Token to the application, e.g. username.
• Identify Provider Aliases. Cause one identity provider to alias another.