Create Client Custom Rest API in Access Management 2.0

Introduction

In enterprise identity and access management systems, managing clients (also known as applications or service integrations) is a critical capability. While Access Management 2.0 offers powerful admin tools through its console and built-in APIs, there are often scenarios where organizations need customized REST APIs tailored to their workflows, security controls, or automation pipelines.

Client configuration fields description

client_id

Definition:
The client_id is a unique identifier for a client (application) registered with Access Management 2.0. It is how Access Management 2.0 recognizes and distinguishes between different applications or services that want to authenticate and authorize users.

It must be globally unique within a realm and is typically used during login flows, token requests, and API calls.

Usage in OAuth/OIDC Flows:
Passed as a parameter in authorization requests:
https://myapp.example.com/auth?...&client_id=my-app&...

Access Management 2.0 uses the client_id to:

• Match client settings
• Apply protocol mappers
• Verify redirect URIs and scopes

Example:

{
    "client_id": "testclient"
}

Real-life analogy:
Think of client_id like a badge number at a secure facility:

• Every employee (application) has a unique badge ID.
• The badge helps identify the employee.
• Systems use it to verify identity, enforce access rules, and track activity.

client_secret

Definition:

The client_secret is a confidential key associated with a client in Access Management 2.0. It is used to authenticate the client to the Access Management 2.0 server—typically in confidential clients such as backend services or server-side applications. It is similar to a password and must be kept secret. Leaking it can compromise the security of the client application.

Example :

{
    "client_secret": "******"
}

Real-life Analogy:

Think of client_secret as the combination to a secure locker:

• The client_id tells you which locker to open.
• The client_secret authorizes you to access it.
• If someone knows your combination, they can access your locker—hence why it must be kept private.

scope

Definition:

A scope in OAuth2/OpenID Connect defines what access permissions the client is requesting from the authorization server (e.g., Access Management 2.0). It represents the level of access the client application wants on behalf of the user.

Common Scopes:

Example:

{
  "scope": ["openid", "profile"]
}

Real-life Analogy:

Scopes are like access levels on a visitor badge:

• A badge with only openid lets you into the building (authentication only).
• Add profile, and you can access someone’s name and office.
• Add email, and now you get their contact information too.
• Each scope adds more access permissions, just like adding stickers or barcodes to a badge to unlock more areas.

authorized_grant_types

Definition:

authorized_grant_types specifies how a client is allowed to interact with the authorization server to obtain tokens.
These are OAuth2 flows that determine the security context and method of exchanging credentials or tokens.

Common Grant Types

Example:

{
  "authorized_grant_types": ["password", "authorization_code"]
}

Real-life Analogy: Grant types are like ticket types at a train station:

• authorization_code: Reserved ticket bought online — verify ID at pickup (secure, indirect).
• client_credentials: Company ID badge lets an employee through without a ticket (no user).
• password: Giving someone your credentials to get a ticket (risky).
• refresh_token: A return pass you can reuse for a second trip without queuing again.

redirect_uri

Definition:

redirect_uri is the callback URL where the authorization server (e.g., Access Management 2.0) redirects the user after they successfully authenticate.
It must be registered by the client to prevent redirection attacks.

Why It Matters:

• Acts as a security check — only exact matches to registered redirect_uri values are allowed.
• Primarily used in authorization_code and implicit grant flows.

Example:

{
    "redirect_uri": "https://www.getpostman.com/oauth2/callback"
}

Real-life Analogy:

It’s like telling a delivery person the exact address to return your package after verifying your ID.
If the address doesn’t match the one you registered, the delivery is denied to prevent fraud.

access_token_validity

Definition:

access_token_validity specifies the lifetime (in seconds) of the access token issued to the client after successful authentication.

Why It Matters:

• Controls how long a client can access resources before needing to refresh the token.

• Balances security and performance — shorter durations increase security; longer ones reduce re-authentication load.

  Example:

{
    "access_token_validity": 1800
}

Real-life Analogy:

It’s like a time-limited visitor badge at a corporate office — once it expires, you need to go back to reception (authentication server) to get a new one.

srvc_ac_user_name

Definition:
srvc_ac_user_name typically refers to the username or identifier of a service account associated with a client in systems like Access Management 2.0 or OAuth-based identity platforms.

Purpose:
This service account is used when the client authenticates using the Client Credentials Grant, allowing server-to-server communication without end-user interaction.

Note:
srvc_ac_user_name is username of user already existing in Org component. This user needs to be a Robot user.

Example:

{
    "srvc_ac_user_name": "robot4@test.com"
}

Real-life Analogy:

It’s like giving a building’s cleaning robot its own ID badge. The robot doesn’t represent a person, but it still needs credentials to enter and operate in restricted areas — just like a service account user enables automated system access without human involvement.

Sample responses from API

Create client with unique clientId

Create client with existing clientId

srvc_ac_user_name is missing

Service Account user is not defined as robot user in orgComponent