Authorization and Authentication

Database Tools uses OAuth 2.0 for secure authentication and authorization.

• SSO-based sign in: Users authenticate through IAM or Single Sign-On (SSO) using OAuth 2.0.
• Per-user authorization: Access is enforced based on the user’s group memberships and assigned application roles..
• Short-lived token: The MCP client calls the MCP Server with a short-lived access token.
• No password sharing: The MCP Server performs a secure, backend token exchange to obtain the tokens required to act in the user context and request downstream access without exposing credentials to the user or client.
• Scoped, short-lived database access: The MCP Server obtains a scoped token specifically for the required database operations and resources. It is time-bound and limited in privileges.
• Trust boundaries and validation: Tokens are validated by the appropriate identity services.
• Auditability: Authentication and authorization events are logged to support security monitoring and compliance.
• Common failure outcomes: If the user is not assigned an application role or the token is invalid or expired, the request is rejected with an authorization error and the user may need to reauthenticate or request access.

The following diagram depicts an end-to-end flow where a user with IAM application roles uses an MCP client to call the Database Tools MCP Server, which connects to Oracle Database Cloud Service using a Database Tools Connection configured for token-based IAM database authentication.

The diagram also shows how the user’s IAM identity is propagated to the database. It also highlights the database-side setup for IAM users, that is, creating a database user identified globally by an IAM principal name.

The following steps describe how a user request is authenticated, authorized, and executed from the MCP client to the database through the MCP Server.

1. The user signs in using IAM SSO and the MCP client obtains an access token.
2. The client calls the MCP Server with Authorization: Bearer <token>.
3. The MCP Server validates the token and the user’s roles.
4. The MCP Server obtains the required time-bound database authorization.
5. The MCP Server executes the request and returns results.

OAuth 2.0 Client Credentials Flow

For service-to-service scenarios where no user interaction is required, the OAuth 2.0 Client Credentials flow can be used. In this flow, a confidential client configured in the identity domain requests an access token from the authorization server using the token endpoint. The client must be assigned the appropriate scopes and roles to access the MCP Server.

All communication between MCP clients and the MCP Server is performed over HTTPS, ensuring encryption in transit and protection of authentication tokens.