Adding Clients

As new clients or applications are integrated into, or otherwise given access to, the Telicent CORE platform certain properties need to be configured to ensure the item is authenticated appropriately.

The different properties are grouped into logical sections and are completed as follows.

Basic details

These include the ID, and name of the client.

The identifier is typically a logical derivation of the name. For example, standard clients supplied with Telicent CORE have identifiers that are all lower-case and with spaces in the name replaced with minus characters.

Lastly, it is in this section the authentication method is chosen. In the current version of the Authentication Server just one authentication method is supported: “public client”. More methods are planned to be supported in the future.

Grant types

This configures what the client is authorised to do with regards to authorisation: enable user login, allow access to APIs (without requesting login), and able to renew access (by refreshing tokens) without having to authenticate the user once more.

Scopes

This controls how much information each client can request in descending order of detail, from a simple request for basic OpenID information, through profile information for the user, and then allowing access to the user’s email address.

Token settings

Simply how long the tokens are allowed to persist for before they need to be refreshed.

The first token (“access token”) controls for how long user access can persist before the user needs to be reauthenticated.

The second token (“refresh token”) controls for how long access tokens can keep being refreshed without reauthentication having to occur.

Client settings

These settings revolve around whether the user is required to explicitly grant permission to the client to access the protected resources (the “consent”) and whether proof of the code exchange is required (the “PKCE”), specifically to mitigate against code injection attacks.

Redirect URIs

These are the URIs to which the Auth Server redirects on completion of particular actions, e.g. successful authentication.

Post logout URIs

Similarly, these are the URIs to which the Auth Server redirects on completion of logout.

As with all items the action can be cancelled or the new item saved.