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. See Appendix A for more information on which API endpoints (and methods) can be used by the different client types.

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 endpoints. 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

Back to top

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 endpoint.

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.


Appendix A: Which API Clients Can Access Which API Endpoints?

Back to top


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 endpoints. Note that these tables are designed to show you what you can do, in general, when it comes to API clients and API endpoints; 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

No

No

No

No

direct_read_access

No

No

No

No

direct_access

No

No

No

No

owner

Yes

Yes

Yes

Yes



Configuration APIs: Entity and Entity Types


Feature

GET

PUT / MODIFY

POST/ CREATE

DELETE

login_client

No




direct_read_access

Yes, but not the attribute endpoints




direct_access

Yes




owner

Yes






Configuration APIs: Flows and Flow Management


Feature

GET

PUT / MODIFY

POST / CREATE

DELETE

login_client

No

No

No

No

direct_read_access

No

No

No

No

direct_access

Yes

Yes

Yes

Yes

owner

Yes

Yes

Yes

Yes




Entity and Entity Type APIs: Entities


Feature

GET

PUT / MODIFY

POST / CREATE

DELETE

login_client

No

No

No

No

direct_read_access

Yes

No

No

No

direct_access

Yes

Yes

Yes

Yes

owner

Yes

Yes

Yes

Yes



Entity and Entity Type APIs: Entity Types


Feature

GET

PUT / MODIFY

POST / CREATE

DELETE

login_client

No


No

No

direct_read_access

Yes


No

No

direct_access

Yes


No

No

owner

Yes


Yes

Yes



Entity and Entity Type APIs: Access Schemas


Feature

GET

PUT / MODIFY

POST / CREATE

DELETE

login_client

No


No

No

direct_read_access

Yes


No

No

direct_access

Yes


No

No

owner

Yes


Yes

Yes




Legacy Client and Settings APIs: Clients


Feature

GET

PUT / MODIFY

POST / CREATE

DELETE

login_client

No

No

No

No

direct_read_access

No

No

No

No

direct_access

No

No

No

No

owner

Yes

Yes

Yes

Yes



Legacy Client and Settings APIs: Published Settings


Feature

GET

PUT / MODIFY

POST / CREATE

DELETE

login_client

No

No

No

No

direct_read_access

No

No

No

No

direct_access

No

No

No

No

owner

Yes

Yes

Yes

Yes



Legacy Client and Settings APIs: Application and Client Settings


Feature

GET

PUT / MODIFY

POST / CREATE

DELETE

login_client

No

No

No

No

direct_read_access

Yes

No

No

No

direct_access

Yes

No

No

No

owner

Yes

Yes

Yes

Yes




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 endpoint. 




Webhooks v3 


Not applicable. Webhooks v3 uses token-based authentication: you do not use a client ID and client secret when calling a Webhooks endpoint. 




Authentication APIs


Four of the authentication endpoints require you to us an owner ID client and client secret to authentication:


·/access/getAccessToken

·/access/getAuthorizationCode

·/access/getVerificationCode

·/oauth/token


The remaining endpoints require a token and the client ID (bot not the client secret) of a login client.