1. How do I use AI Agent Studio?
  2. How does authentication differ between the A2A and invokeAsync APIs?

How does authentication differ between the A2A and invokeAsync APIs?

A2A doesn't introduce a separate authentication model. It uses the same IDCS or OCI IAM OAuth setup and bearer-token pattern that's used to call Fusion Applications AI endpoints such as invokeAsync.

Application credentials → OCI IAM access token → Authorization: Bearer <access_token> → Fusion AI API

An external application that's configured to obtain an appropriate Fusion Applications AI access token can use that token with either invokeAsync or A2A. The differences between the APIs are in their endpoints, payloads, and result-retrieval formats, and not in how the caller authenticates.

Here's what's same for A2A API and invokeAsync API authentication:

Authentication Element invokeAsync A2A
Access token OAuth access token issued by OCI IAM Same token can be reused
Authorization Fusion roles, permissions, and access to the published Agent Team Same authorization model
Fusion AI scope urn:opc:resource:fusion:<pod>:fusion-ai/ Same
HTTP authentication Authorization: Bearer <access_token> Same
Identity provider OCI IAM identity domain associated with the Fusion Applications environment Same
OAuth client Confidential client registered for the external application Same

Here's what's different for A2A API and invokeAsync API authentication:

For these options, only the API contract changes.

Operation invokeAsync A2A
Identifier Job ID Task ID
Call POST /api/fusion-ai/orchestrator/agent/v2/<workflowCode>/invokeAsync JSON-RPC message/send at /api/fusion-ai/orchestrator/a2a/v1/<workflowCode>
Payload format Fusion Applications invokeAsync request and response A2A JSON-RPC request and response
Retrieve result GET .../status/<jobId> JSON-RPC tasks/get
The application must send the same bearer-token header on discovery, invocation, and result-retrieval requests. For message/stream, API polling isn't required on both sides.

Configuration

The Fusion Applications IAM/security administrator must do the following:

  1. Register a confidential OAuth client in the identity domain associated with the Fusion Applications environment.
  2. Enable the required OAuth grant.
  3. Authorize the Fusion Applications AI resource scope.
  4. Configure client authentication using a signed client assertion or client ID and secret, as supported by the client configuration.
  5. Assign the roles and permissions required to access the selected published workflows.

The access token proves the caller's identity. Fusion Applications authorization determines whether that identity can discover, call, or retrieve results for a particular workflow. Successfully retrieving an A2A agent card doesn't necessarily prove access to process.

Application-only Flow

For service-to-service access without a signed-in user, use the OAuth Client Credentials grant. The resulting token represents the OAuth client application.

The following client-secret example shows the token request used during validation:

ACCESS_TOKEN=$(curl --fail --silent --show-error \
  --user "${CLIENT_ID}:${CLIENT_SECRET}" \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode "scope=${FAI_SCOPE}" \
  "${IDCS_URL%/}/oauth2/v1/token" | jq -er '.access_token')

Oracle's OAuth guidance recommends signed client assertions. Whichever supported client-authentication method is used, the runtime calls use the access token returned by IAM:

Authorization: Bearer <access_token>

Production applications must cache the token securely and obtain a new token before it expires.

Identity Clarification

The OAuth grant determines the identity represented by the access token:

  • client_credentials produces an application-only token.
  • The JWT User Assertion grant produces a token representing a user.

Both token types use the same bearer-token header at the runtime API. A2A fields such as role: "user" describe the role of a conversational message. They don't change the identity represented by the access token.

Additional Information