OAuth clients can be stored in the Curity Identity Server’s configuration itself. That’s very convenient and sufficient in many cases.
However, for deployments where the number of clients is higher than a few dozen, or where it is desirable to perform client management using an external system, OAuth clients may be stored in a compatible Data Source.
Clients stored in a Data Source are referred to as Database Clients.
When Database Clients are used, Curity will load OAuth client configuration from the configured Data Source as well as from its own configuration and Dynamic Client Registration.
OAuth clients can be used to perform authorization flows in Curity in the exact same way regardless of whether they are Database Clients, Dynamic Clients or Curity Configuration Clients.
Hint
To give the server a hint about a client being stored in a Data Source, prepend db- to the client_id. That tells Curity to look for the client first in the configured Data Source, which helps avoiding conflicts with configuration clients while potentially making it faster to find a database client.
db-
client_id
A related, but independent Curity feature is Dynamic Client Registration, which also allows storing clients in a Data Source.
Dynamic Client Registration Clients are based on the OpenID Connect Dynamic Client Registration specification, which limits the features that can be supported by both the API and by the actual clients in the Curity Identity Server.
Another difference is that Dynamic Client Registration attempts to support self-managing OAuth clients. It can be cumbersome to try and have centralized management of Dynamic Client Registration clients (which is possible through Dynamic Client Registration Management Clients). In other words, Dynamic Client Registration is not a general client management solution and does not integrate fully with Curity features.
Database Clients match more closely the Curity data model for configuring OAuth clients, allowing more Curity features to be utilized while enabling faster evolution of the API to support new use cases.
To enable Database Clients:
If authorization access is configured in the Token Service, the Database Clients GraphQL API will become available for external applications to manage clients. Otherwise, the only way to manage Database Clients is through the DevOps Dashboard (which must be configured to allow access to Database Clients).
Warning
Modifying clients directly in the database instead of using the GraphQL API or the DevOps Dashboard can cause the clients to become invalid, and hence inaccessible from the Curity Identity Server. Removing Curity configuration that is used by Database Clients (e.g. encryption keys, authenticators) without updating the affected clients may also cause problems. Care must be taken to update Curity configuration and Database Clients in tandem to make sure there is always consistency between them.
Note
Database Clients were introduced in version 8.4.0, and require Database changes when migrating from older Curity versions. Please consult Upgrading from 8.3.X to 8.4.0 for details on how to change the SQL Database in order to support Database Clients.
The first thing to do to enable Database Clients is to configure a Data Source for storing clients in each Token Service Profile.
The example below shows where in the Token Profile configuration this can be achieved:
<authorization-server xmlns="https://curity.se/ns/conf/profile/oauth"> <database-client> <client-data-source>data-source-id</client-data-source> </database-client> </authorization-server>
In the Admin UI, you can find the Database Client setting under the Token Service’s General tab:
Database Client
General
Fig. 148 Enabling Database Clients in the Admin UI
Only DataSources that support Database Clients can be selected (an error occurs if the selected Data Sources doesn’t). The only built-in Data Source implementation that currently supports Database Clients is the JDBC Data Source.
The Oracle Database, while supported via the JDBC Data Source, currently presents issues when used for Database Clients and hence it is not recommended to use it. This will be fixed in future releases.
The next step is to enable the GraphQL API Endpoint.
This can be achieved by going to the Deployment > Endpoints section and adding a new endpoint of type oauth-client-graphql-api.
Deployment > Endpoints
oauth-client-graphql-api
Fig. 149 Creating a Database Client GraphQL Endpoint.
For the GraphQL API to be usable without the Curity DevOps Dashboard, it is necessary to configure an appropriate Authorization Manager in the relevant Token Service which can authorize users to access the API.
Not all Authorization Managers support GraphQL APIs. As of writing, the Groups Authorization Manager and Attribute Authorization Manager have full support for Database Clients (added in Curity version 8.4.0).
Check Authorization Managers for more information.
To make Database Clients accessible via the DevOps Dashboard so that clients can be managed easily via a simple User Interface, after enabling Database Clients (as explained in the previous section), make sure that Client access is allowed in the Dashboard Settings.
The Token Service’s Authorization Manager is not used by the DevOps Dashboard! In fact, it is not necessary to configure one in order to manage Database Clients via the DevOps Dashboard - only the Dashboard authorization settings apply when authorizing the Dashboard client.
Example:
Fig. 150 Displaying a few Database Clients in the DevOps Dashboard.
Database clients have nearly the same configuration model as configuration clients.
Tip
See OAuth Client Configuration for details about the OAuth client’s data model, and check also the GraphQL schema which can be obtained with any GraphQL Tool by pointing it at the configured endpoint URL.
The GraphQL API is self-documented. Check the GraphQL APIs documentation for more information about using Curity’s GraphQL APIs and obtaining the full GraphQL schema.
Upon any operation on a database client, warnings can be returned. They are reporting issues that should be better to address, but that did not prevent the requested operation to succeed. They are returned in the database client’s metadata, in the warnings field.
warnings
Even though Database Clients are nearly identical in functionality to Configuration Clients, there are a few differences as noted below:
properties
typedProperties