API clients and permissions
API clients control access to the Registration API. The features that are applied to an API client control the base level of read and write access it will have to user records and application management functionality. Additional access control can be put in place with client access schemas.
Client feature sets
The following features may be set for an API client. If client features are not set on creation, they can be added or updated through the Console or using the Client and Settings APIs.
| Feature | Description |
|---|---|
| access_issuer | This type of client has permission to issue access tokens scoped for use with all clients. |
| direct_access | This type of client has read and write access to all user records. You can also use this client type to manage flows and flow components. |
| direct_read_access | This type of client has read access to all user records. |
| login_client | This type of client is scoped with read and write access to only the currently authenticated user. It can only be used with sign-in and registration based API operations. All client-side API calls should be made using a client with this feature. |
| metadata | This type of client will not update the lastUpdated attribute when posting updates to a user record. This client feature set is commonly used with third-party integrations. This type of client can only be provisioned by the Akamai team. Note. Do not update a client with the metadata feature through the Console - this will remove the feature and may cause unexpected results. |
| owner | This type of client has complete admin access to the application. The application owner credentials should only be used for administrative configuration purposes, such as provisioning additional API Clients, updating client settings, and managing your schema. |
Client access schemas
API clients can also be restricted with read or write access to a subset of specific attributes within an entity type. Custom access schemas are commonly used for integrations with third-party applications. This allows controlled access to the user database based on the attributes that an application needs access to. This is configured on a per-client basis using the /entityType.setAccessSchema operation.
This diagram provides some more context about how authorization can be managed for API clients. Integrations with other systems such an Email Service Provider, Ad Server, or CRM make use of API clients can query the database and receive result sets used for data synchronization or data analysis efforts. Each of these clients can be granted access to only the attributes needed to support their specific business need as opposed to providing access to the whole record.
Within the diagram:
-
The API Client assigned to the Email Service Provider only has access to the user’s email address, first name, and opt-ins.
-
The API Client assigned to the Ad Server only has access to the user’s DOB and gender.
-
The API Client assigned to the Recommendation Engine only has access to the user’s Interests.
Which API clients can access which API operations?
The following tables list the Identity Cloud REST APIs and indicate the type of access (if any) that the various API client types have to those operations. Note that these tables are designed to show you what you can do, in general, when it comes to API clients and API operations; for example, you can generally use a direct_access client to call the flow management APIs. Just keep in mind that there might be an occasional exception to these general rules.
Configuration APIs: Clients and Settings
| Feature | GET | PUT / MODIFY | POST / CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | ✗ | ✗ | ✗ |
| direct_read_access | ✗ | ✗ | ✗ | ✗ |
| direct_access | ✗ | ✗ | ✗ | ✗ |
| owner | ✓ | ✓ | ✓ | ✓ |
Configuration APIs: Entity and Entity Types
| Feature | GET | PUT / MODIFY | POST/ CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | n/a | n/a | n/a |
| direct_read_access | ✓ (but not the attribute operations) | n/a | n/a | n/a |
| direct_access | ✓ | n/a | n/a | n/a |
| owner | ✓ | n/a | n/a | n/a |
Configuration APIs: Flows and Flow Management
| Feature | GET | PUT / MODIFY | POST / CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | ✗ | ✗ | ✗ |
| direct_read_access | ✗ | ✗ | ✗ | ✗ |
| direct_access | ✓ | ✓ | ✓ | ✓ |
| owner | ✓ | ✓ | ✓ | ✓ |
Entity and Entity Type APIs: Entities
| Feature | GET | PUT / MODIFY | POST / CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | ✗ | ✗ | ✗ |
| direct_read_access | ✓ | ✗ | ✗ | ✗ |
| direct_access | ✓ | ✓ | ✓ | ✓ |
| owner | ✓ | ✓ | ✓ | ✓ |
Entity and Entity Type APIs: Entity Types
| Feature | GET | PUT / MODIFY | POST / CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | n/a | ✗ | ✗ |
| direct_read_access | ✓ | n/a | ✗ | ✗ |
| direct_access | ✓ | n/a | ✗ | ✗ |
| owner | Sometimes | n/a | ✓ | ✓ |
Entity and Entity Type APIs: Access Schemas
| Feature | GET | PUT / MODIFY | POST / CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | n/a | ✗ | ✗ |
| direct_read_access | ✓ | n/a | ✗ | ✗ |
| direct_access | ✓ | n/a | ✗ | ✗ |
| owner | ✓ | n/a | ✓ | ✓ |
Legacy Client and Settings APIs: Clients
| Feature | GET | PUT / MODIFY | POST / CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | ✗ | ✗ | ✗ |
| direct_read_access | ✗ | ✗ | ✗ | ✗ |
| direct_access | ✗ | ✗ | ✗ | ✗ |
| owner | ✓ | ✓ | ✓ | ✓ |
Legacy Client and Settings APIs: Published Settings
| Feature | GET | PUT / MODIFY\ | POST / CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | ✗ | ✗ | ✗ |
| direct_read_access | ✗ | ✗ | ✗ | ✗ |
| direct_access | ✗ | ✗ | ✗ | ✗ |
| owner | ✓ | ✓ | ✓ | ✓ |
Legacy Client and Settings APIs: Application and Client Settings
| Feature | GET | PUT / MODIFY | POST / CREATE | DELETE |
|---|---|---|---|---|
| login_client | ✗ | ✗ | ✗ | ✗ |
| direct_read_access | ✓ | ✗ | ✗ | ✗ |
| direct_access | ✓ | ✗ | ✗ | ✗ |
| owner | ✓ | ✓ | ✓ | ✓ |
Social Login APIs
Not applicable. Most of the Social Login APIs use the Social Login API Key, which can be found on the Settings page of the Social Login Dashboard: look for the setting API Key (Secret).
Hosted Login (OpenID Connect/OAuth 2)
Not applicable. Hosted Login uses token-based authentication: you do not use a client ID and client secret when calling a Hosted Login operation.
Webhooks v3
Not applicable. Webhooks v3 uses token-based authentication: you do not use a client ID and client secret when calling a Webhooks operation.
Authentication APIs
Three of the authentication operations require you to use the client ID and client secret of an owner client, an access_issuer, client, or a direct_access client when making an API call:
- /access/getAccessToken
- /access/getAuthorizationCode
- /oauth/token
Meanwhile, the /access/getVerificationCode operation requires the client ID and client secret of an owner client or a direct_access client.
The remaining operations require a token and the client ID (but not the client secret) of a login client.
Updated about 2 years ago