# Authentication Clients

- Link: https://www.agilicus.com/anyx-guide/authentication-clients/
- Published: 2024-05-14T00:24:50+00:00
- Author: Don Bowman

1. [Home](https://www.agilicus.com/)
 2. Authentication Clients

![Authentication Clients (clientid)](https://www.agilicus.com/www/61bc3dcf-clients.
svg)

OAUTH2 client-id

---

## Authentication Clients

Advanced configuration of per-application settings on authentication.

[CONTACT](https://www.agilicus.com/contact-us/)

## Authentication Clients

The Authentication Clients implement OpenID Connect [client id](https://openid.net/specs/openid-connect-registration-1_0.html).
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](https://www.agilicus.com/anyx-guide/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](https://datatracker.ietf.org/doc/html/rfc6749))
   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.

[⌊08681b7f-image⌉⌊08681b7f-image⌉[

[⌊b968ed35-image⌉⌊b968ed35-image⌉[