Register with AIGW

AIGW exposes a Dynamic Client Registration endpoint so an agent can obtain its own OAuth client credentials at runtime.

Registration request

The supplied playground successfully used:

POST https://api.aigw.eval.loginid.ai/api/register
Content-Type: application/json

{
  "client_name": "My agent",
  "redirect_uris": ["https://agent.example.com/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "client_secret_post"
}

Requirements observed in the supplied run

• Redirect URIs must be absolute HTTPS URLs.
• Choose the resource scope later, in the authorization request.

Don't send resource scopes at registration

Do not include resource scopes in the DCRDCRDynamic Client Registration (RFC 7591): an agent registers itself as an OAuth client at runtime, with no manual setup. request. A single non-registrable scope makes AIGW reject the whole registration.

Registration response

A successful request returned 201 with values including:

• client_id;
• client_secret;
• client_secret_expires_at: 0 in the observed run;
• default granted scope string;
• redirect-host/domain information;
• verification method;
• core AIGW issuerCore issuerThe shared AIGW authorization server that issues agent-facing access tokens and hosts the token endpoint./endpoints.

Persist the client ID/secret securely according to your agent runtime model.

Agent approval

The first time a newly registered agent asks for a ResourceResourceThe downstream system registered in a Project. Its kind (Token exchange or OAuth client) decides the role AIGW plays., the ProjectProjectThe isolation boundary for an integration. It holds Resources, agents and agent policy, end users, and Proxy clients.'s Agent policy decides its status. By default every agent is Approved automatically. A Project can instead hold agents for review — they then appear under Agents → Pending, and authorization is refused until the project operator approves or rejects them — or reject them outright.

Proving who your agent is can earn a more open decision when the operator has configured it: AIGW recognizes proofs such as a platform-trusted domain, Web Bot AuthWeb Bot AuthAn agent signs its HTTP requests (RFC 9421 HTTP Message Signatures) with keys published in its own signature directory. request signatures, reverse DNSReverse DNSForward-confirmed reverse DNS: the agent's IP address resolves to a name in its domain, and that name resolves back to the IP., a KYAKYAKnow Your Agent: a credential from a third-party issuer that vouches for an agent. credential from an accepted issuer, and hosted client metadata (CIMDCIMDClient ID Metadata Document: an agent uses an HTTPS URL as its client_id and serves its metadata there, so no registration call is needed.).

If authorization fails immediately after successful DCR, ask the project operator to check the agent's status and the Project's Agent policyAgent policyProject or Resource rules that approve, hold, or reject an agent the first time it asks for a Resource. The default approves everyone. before debugging PKCEPKCEProof Key for Code Exchange: binds an authorization request to the later code exchange so a stolen code is useless. or the user login flow.

Continue to Request authorization.