--- title: Credential Issuance | Keycard description: Overview of the different methods Keycard offers to issue credentials. --- Keycard STS supports several methods for issuing credentials, each suited to different access scenarios. Every method produces a credential scoped to a specific [resource](/platform/concepts/resources/index.md). What varies is how the caller [authenticates](/platform/concepts/applications/#credentials/index.md) and whether access is on behalf of a user. The credential itself is determined by the resource’s [credential type](/platform/concepts/resources/#credentials/index.md): a [Keycard-issued token](/platform/concepts/resources/#keycard-issued-tokens/index.md), a [vaulted static credential](/platform/concepts/resources/#vaulted-static-credentials/index.md), or [brokered access](/platform/concepts/resources/#brokered-access/index.md) from an external provider. Every issuance is recorded in the [audit log](/console/audit-log-export/index.md), evaluated against the zone’s [access policies](/console/access-policies/index.md), and, when a user is involved, requires [consent](/platform/concepts/applications/#consent/index.md). ## User Delegation Used when an application needs to access resources on behalf of a user. The user authenticates interactively and the application receives credentials it can use to act for that user. Keycard STS implements this using the authorization code flow with PKCE ([OAuth 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-15)). The application redirects the user to Keycard STS, the user authenticates via the zone’s identity provider, and the application exchanges the resulting authorization code for credentials. Confidential applications authenticate with their client credentials during the exchange; public applications (native apps, CLI tools, MCP clients) rely on PKCE alone. During this flow, Keycard STS also handles: - **Consent** — Keycard STS evaluates [consent](/platform/concepts/applications/#consent/index.md) requirements for the application. If consent is required and has not been previously granted, the user sees a consent screen before the authorization code is issued. - **Brokered credentials** — If the application has [dependencies](/platform/concepts/applications/#dependencies/index.md) on external resources, the user authorizes the zone to [broker credentials](/platform/concepts/providers/#brokered-credentials/index.md) for each dependency, so that they are available for issuing later. Keycard STS returns a credential, a refresh token, and (if the `openid` scope was requested) an ID token. User Application Resource Keycard STS brokered credentials User authorize Application authorization codeKeycard STS credential Resource ### Refreshing Used to obtain new credentials without requiring the user to interact again. Covers two cases: replacing an expired credential for the same resource, and obtaining a credential for a different resource using the existing authorization. If the target resource requires brokered credentials that have not been established, Keycard STS returns an error indicating user interaction is needed. ## Autonomous Access Used by an application to access resources on its own behalf, with no user involved. Covers service-to-service, machine-to-machine, and agent-to-agent communication. The application authenticates directly to Keycard STS using the client credentials flow ([OAuth 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-15)) with any of the supported [application credentials](/platform/concepts/applications/#credentials/index.md) (client secret, workload identity, or URL credential). Public credentials are not supported for autonomous access because there is no user present to perform PKCE-protected authorization. No user context is available. Because there is no user, client credentials cannot directly obtain [brokered access](/platform/concepts/resources/#brokered-access/index.md) to external resources. To access brokered resources on behalf of a user, an autonomous application can use [impersonation](#impersonation). Application Resource Keycard STS Application client credentialsKeycard STS credential Resource ## Delegation Chaining Used when an application needs to access a downstream resource to fulfill a request on behalf of a user. For example, a user authorizes an MCP client, the MCP client calls an MCP server, and the MCP server needs to call an external API. Each hop in this chain requires its own credential, but the user only authenticates once. The application at each hop presents the credential it received (the subject token) along with the target resource to Keycard STS using token exchange ([RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693)). Keycard STS validates the subject token, evaluates [policies](/console/access-policies/index.md) to check that the application and subject are allowed to access the resource, and returns a new credential scoped to the requested resource. The new credential carries the full chain of delegation, so policy and audit logs can trace the path from the original user through every intermediary. If the subject has not authorized access, Keycard STS returns an error code letting the application know that user interaction is required to establish credentials. The application authenticates itself using any of the [application credentials](/platform/concepts/applications/#credentials/index.md) supported for [autonomous access](#autonomous-access). User MCP Client MCP Server Resource Keycard STS brokered credential User authorize MCP Client authorization codeKeycard STS user token MCP Server token exchangeuser tokenKeycard STS brokered credential Resource ## Impersonation Used by an autonomous application to act as a specific user without the user being present. The application authenticates using [autonomous access](#autonomous-access) and then uses token exchange to impersonate the user. Requires prior [user delegation](#user-delegation) to establish brokered credentials for the resources the application will access. Using token exchange ([RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693)), instead of a subject token from an active user, the application provides a substitute-user token containing the user’s [identifier](/platform/concepts/users/#identifiers/index.md). Keycard STS resolves the identifier to the user and issues a credential as if that user had made the request. INTERACTIVE SETUP User Landing Page Keycard STS brokered credential NON-INTERACTIVE Background Agent Resource INTERACTIVE SETUP User authorize Landing Page storeKeycard STS NON-INTERACTIVE Background Agent token exchangeKeycard STS substitute-user token credential Resource Impersonation is forbidden by default policies. [Policy](/console/access-policies/index.md) must explicitly permit the application to impersonate users, and the application must be configured with [consent](/platform/concepts/applications/#configuration/index.md) set to `implicit`, because the user is not present during the exchange.