Authentication

Set up inbound authentication to control access to agents and outbound authentication to securely access OCI resources.

Configure authentication on the hosted application. Associated hosted deployments inherit these settings. Select identity domain bearer token, identity domain browser session, OCI IAM, or No authentication based on how clients access the application.

Inbound Authentication

Inbound authentication controls who can access your hosted agents. Hosted applications support the following authentication options:

  • Identity domain bearer token: Clients send an OAuth access token issued by an OCI IAM identity domain. The service validates the token before routing the request to the hosted deployment. See Setting Up Identity Domain Bearer Token Authentication.
  • Identity domain browser session: Uses the OAuth 2.1 Authorization Code flow with Proof Key for Code Exchange (PKCE). Browser users are redirected to an OCI identity domain to sign in. The hosted application service obtains an access token on their behalf and establishes a browser session that uses a session cookie. See Identity domain browser session.
  • OCI IAM: Clients sign requests according to OCI IAM request-signing requirements. See Authentication.
  • No authentication: The platform routes requests without authenticating the caller. Use this option for public content or when your application manages authentication. See No authentication.

For API configuration, see InboundAuthConfig. For identity domain authentication, also see IdcsAuthConfig. Omit idcsConfig when using NO_AUTH_CONFIG.

View the selected authentication type on the application's Configuration tab.

Using No Authentication

Select No authentication when the platform doesn't need to authenticate incoming requests. Examples include public web content, applications with their own sign-in flow, and service integrations where the application validates credentials.

Anyone who can reach the endpoint can send requests without platform-managed authentication. If access needs restriction, implement authentication and authorization in your application. Network settings determine which clients can reach the endpoint.

No separate tenancy enrollment is required. TLS, the configured public or private endpoint, and service limits still apply. OCI IAM permissions are still required to manage the application and access other OCI services from it.

When using the API, set inboundAuthConfig.inboundAuthConfigType to NO_AUTH_CONFIG and omit idcsConfig. Omitting inboundAuthConfig from an update leaves the current authentication configuration unchanged. See InboundAuthConfig.

If you use identity domain browser session authentication and need public access only for selected paths, configure Public access path patterns. For example, you can allow access to /assets/* while retaining sign-in for other paths. See Identity domain browser session.

Outbound Authentication

With outbound authentication, deployed agent applications can securely access other OCI resources within a tenancy.

Access is granted by defining OCI IAM policies that authorize the agent application (as a resource principal) to perform specific actions on specified resources. These policies decide the scope of access based on the principle of least privilege.

After deployment, the platform automatically provisions a Resource Principal Session Token (RPST) for the agent workload. The RPST is securely injected into the container runtime, allowing the application to authenticate to OCI services without using long-lived credentials such as API keys or user tokens.

Within the container, the agent uses the OCI SDK with the resource principal authentication provider. The SDK automatically retrieves and refreshes the RPST, enabling secure access to authorized OCI services such as Object Storage, Autonomous AI Database, Vault, and Streaming.