Clients are entities that can request the Carerix Identity & Access Management platform to authenticate a user. Most often, clients are applications and services that want to use the Identity & Access Management platform to secure themselves and provide a single sign-on solution.
Setting up a client in Carerix
When in the identity & access menu, select the Clients tab. Click on the new button and select whether you want to use a public client or a confidential client.
Whether you choose the confidantial or public option depends highly on the nature of the solutution or service you wish to connect. In the context of OAuth 2.0 "confidential clients" and "public clients" refer to different types of applications that interact with the OAuth 2.0 authorization server. The distinction between them primarily concerns their ability to securely handle credentials.
Confidential Clients
Confidential clients are applications that are capable of maintaining the confidentiality of their credentials (e.g., client secret) because they run on a secure server. These applications can securely store and manage sensitive information.
Typical examples of applications that require a confidential client include:
Web applications: Server-side applications that can securely store credentials on the backend server.
Backend services: Services that run on a secure server environment.
Characteristics of confidential clients include:
Client Secret: They use a client secret to authenticate with the OAuth 2.0 authorization server. The client secret is kept secure and not exposed to end users.
Secure Storage: Credentials and other sensitive data are stored securely on the server.
Public Clients
Public clients are applications that cannot securely store credentials because they run on devices or platforms that are potentially accessible to end users. These applications are unable to keep client secrets confidential.
Typical examples of applications that require a public client include:
Single-page applications (SPAs): JavaScript applications that run entirely in the user's browser.
Mobile applications: Apps that run on user devices, such as smartphones or tablets.
Native desktop applications: Apps that run on user desktop computers.
Characteristics of public clients include:
No Client Secret: They do not use a client secret to authenticate with the OAuth 2.0 authorization server, as it would be exposed to end users.
Reduced Trust: These applications are considered less secure due to the inability to protect credentials.
Security Implications
The distinction between confidential and public clients has significant security implications:
Token Handling: Confidential clients can use more secure token handling mechanisms, whereas public clients need to rely on mechanisms that mitigate the risk of token exposure (e.g., using Proof Key for Code Exchange (PKCE) for securing authorization code grants).
Authentication: Confidential clients can authenticate themselves to the authorization server using a client secret, while public clients must rely on other mechanisms since they cannot keep secrets confidential.
In summary: the key difference lies in the ability to securely handle credentials, with confidential clients being able to securely store and manage sensitive information, and public clients being unable to do so. This distinction helps guide the appropriate security measures and OAuth 2.0 flows that should be used by each type of client.
Configure your client
Once you have selected the desired type of client you need to configure it.
Configuration of a confidential client
For a confidential client you need to setup the following fields:
Name: you need to provide a name for your client. You can typically choose the name of the service that is going to connect with through this client. It makes it transparent in the future to see to whom or what access was given with this client.
Code: Code is a user-defined unique identifier. It can be used to query client via the API. It also acts as a prefix for client’s resources, permissions and scopes if such client is a resource server. Format:
urn:{vendor}/{unique name]Default Scopes: scopes define the rights for an application (e.g. website or middle ware) to call an endpoint. Scopes are included in the token and if the scope that is needed for a sepcific endpoint is not present in the token, your request will be rejected (403). Default scopes are always present in the scope claim, regardless of being requested or not.
Optional Scopes: optional scopes need to be called for explicitly in a request. Only then the scope will be included in the scope claim.
⚠️Please note: if a scope is being requested which is not listed as a default, nor as an optional scope, the token retrieval will fail.
Active YES/NO: indicates whether the client can be used (YES) or not (NO)
Permissions: With permissions you can give more granular permissions (Create, Read, Update, Delete) for specific scopes.
Client ID & Client Secret
Once your done with the configuration, you can store the new client by clikcing the save button. A pop up will appear providing you with the client ID and a client secret which are needed for your service to connect with this client.
⚠️Please note: while the clientID can be retrieved in your client configuration in Carerix at any point in time, the client secret will be provided only once! Make sure to keep copy it exactly. If you lost it, you will need to create a new client from scratch.
Configuration of a public client
For a public client you need to setup the following fields:
Name: you need to provide a name for your client. You can typically choose the name of the service that is going to connect with through this client. It makes it transparent in the future to see to whom or what access was given with this client.
Code: Code is a user-defined unique identifier. It can be used to query client via the API. It also acts as a prefix for client’s resources, permissions and scopes if such client is a resource server. Format:
urn:{vendor}/{unique name]URLs specification:
Web Origins:
Consent Required:
Home URL: provide the default URL for when the auth server needs to redirect or link back to the client
Active: indicates whether the client can be used (YES) or not (NO)
Default Scopes: scopes define the rights for an application (e.g. website or middle ware) to call an endpoint. Scopes are included in the token and if the scope that is needed for a sepcific endpoint is not present in the token, your request will be rejected (403). Default scopes are always present in the scope claim, regardless of being requested or not.
Optional Scopes: optional scopes need to be called for explicitly in a request. Only then the scope will be included in the scope claim.
