--- title: Applications | Keycard description: Overview of applications within the Keycard platform. --- Applications are software that access [resources](/concepts/resources/index.md), either autonomously or as a result of a user delegating access to the application. Applications encompass a variety of implementation and deployment characteristics including, but not limited to, web applications running on a server, single-page applications running in a browser, native desktop and mobile apps, command line interfaces, and background daemons. ## Credentials Applications authenticate to a [zone](/concepts/zones/index.md) using credentials. Keycard supports multiple types of application credentials suitable for varying security levels, deployment models, and compatibility requirements. ### Client ID & Secret Keycard supports issuing a client ID and secret (equvalient to a username and password) to applications. The secret is shared between Keycard (where it is stored in secure hashed format) and the application. Keycard verifies the secret to confirm the application’s identity. It is the responsibility of the application to ensure that the secret is stored securely and remains secret. Caution Use of shared secrets poses inherent security risks. Keycard recommends use of credential types other than client ID and secret. ### Workload Identity Applications that run on cloud infrastructure are referred to as *workloads*. Cloud providers, including Amazon Web Services, Google Cloud, and Vercel, issue workload identity tokens to applications running on thier platforms. These workload identity tokens can be used to authenticate to Keycard. Workload identity is a form of federation, although it is not broadly standardized today. Keycard implements support for popular cloud providers, and each provider’s proprietary token format and claim sets. Note Due to lack of standardization, each cloud provider refers to workload identity using slightly different terminology. Confusingly, it is sometimes referred to as OpenID Connect, due to use of shared technology - in particular JSON Web Token (JWT) and JSON Web Key (JWK) sets. OpenID Connect is, however, a user identity protocol rather than a workload identity protocol. ### Public Public applications, such as single-page apps running in a browser, cannot securely store secrets. These applications authenticate using only their client ID, relying on PKCE to protect the authorization code exchange. Public credentials are only valid for [user delegation](/concepts/credentials/#user-delegation/index.md) flows and cannot be used for [autonomous access](/concepts/credentials/#autonomous-access/index.md). ### URL Applications can prove control of a URL using key-based assertions. Applications authenticate by signing an assertion claiming control of a URL. Keycard fetches the public key from metadata associated with the claimed URL in order verify the signature. If the signature is valid, the application has authenticated using the URL as its identity. Keycard supports authenticating URLs using the JWT assertions, as defined by OAuth 2.0 and OpenID Connect. Public keys are fetched from [OAuth Client ID Metadata Documents (CIMD)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document). ## Registration Before an application can make requests to a zone, it must be registered. Registration supplies the information needed by Keycard to authenticate the application, including credentials and URLs. It also supplies metadata, including name and logo, which are displayed to users so that they can make informed consent decisions. Keycard supports private and public modes for user registration. ### Private In private mode, applications must be explicitly registered by an administrator. Upon registration, the application is assigned an identifier and a credential. The application is expected to be configured with this identifier and credential by the administrator, prior to the application being deployed or distributed to users. ### Public In public mode, applications can register dynamically, obtaining an identifier and credential at runtime. This is useful in open, standards-based ecosystems such as MCP. It allows applications to connect to resources, and corresponding authorization servers, without ahead-of-time registration. This eliminates friction for both users and developers. Keycard supports public registration via OAuth 2.0 Dynamic Client Registration Protocol (DCR) and [OAuth Client ID Metadata Document (CIMD)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document). ## Applications as Consumers Applications can consume [resources](/concepts/resources/index.md) directly or while acting on behalf of a user. A coding agent may need repository access, an MCP server may need to call GitHub for the authenticated user, and a backend service may need direct access to a billing API. In Keycard, those relationships are modeled through dependencies, consent, and policy. Dependencies describe what an application is allowed to request; policy decides whether a specific request should receive credentials. ## Dependencies Applications may have dependencies on [resources](/concepts/resources/index.md). Dependencies declare service-to-service relationships, where the application requires access to the resource in order to properly function. For example, a web application may require access to both a database and a billing API. In Keycard, such access is permitted by creating two dependencies of the application, one on the database and another on the billing API. Dependencies only permit access when an application is acting on its own behalf. If the same web application requires access to a user’s calendar, that access is not permitted by a dependency. Rather, policy would have to explicitly allow such access or consent would need to be granted by each user on an individual basis. Because dependencies are used to authorize service-to-service access, it is uncommon to to declare dependencies of native applications, which typically access resources on a user’s behalf. Native applications instead request consent from each user, and should gracefully handle conditions in which consent is not granted. ## Providing Resources Applications may provide [resources](/concepts/resources/index.md). This usually implies a server-side application that, in addition to rendering an interactive user interface (UI), also hosts an API. For example, an appointment scheduling service would offer a web-based application accessed via a browser, as well as a scheduling API called by the application. The same scheduling service may offer an AI-native MCP server that renders UI inside ChatGPT or Claude, in addition to exposing tools to the LLM. Declaring the resources provided by an application is needed in complex multi-service architectures that operate on behalf of a user. For example, consider a user scheduling an appointment with their dentist. Upon signing in, the scheduling application presents the user with a list of times the dentist is available. This list is rendered as a result of an authenticated request to the scheduling API. If the API can obtain a credential to access the user’s calendar, it can make it easier to book an appointment by showing only times that both the user and dentist are available. Because the application provides the API, it can exchange access tokens received in API calls for access tokens needed to call other APIs, such as the user’s calendar API. This creates a chain of delegation. ## Consent When an application needs to access resources on a user’s behalf, Keycard presents a consent screen before the authorization flow continues. ### The consent screen The consent screen shows: - The requesting application’s name and logo - The zone being accessed - The [resources](/concepts/resources/index.md) the application will access - Any [dependencies](#dependencies) on other resources The user can approve the full request or cancel. There is no partial consent. [![Consent screen requesting access to a platform resource](/images/dark/consent-cli.png)](/images/dark/consent-cli.png)[![Consent screen requesting access to a platform resource](/images/light/consent-cli.png)](/images/light/consent-cli.png) Platform resource access [![Consent screen showing a brokered resource dependency](/images/dark/consent-cli-github.png)](/images/dark/consent-cli-github.png)[![Consent screen showing a brokered resource dependency](/images/light/consent-cli-github.png)](/images/light/consent-cli-github.png) Brokered resource dependency [![Transitive consent: application with dependencies](/images/dark/consent-mcp-hierarchy.png)](/images/dark/consent-mcp-hierarchy.png)[![Transitive consent: application with dependencies](/images/light/consent-mcp-hierarchy.png)](/images/light/consent-mcp-hierarchy.png) Transitive consent ### Transitive consent When an application calls another application to fulfill a request, each hop in the chain requires its own credential. Transitive consent covers the full chain in a single prompt, so the user approves access to the application and all downstream applications it [depends on](#dependencies) at once. See [Delegation Chaining](/concepts/credentials/#delegation-chaining/index.md) for how transitive consent fits into credential issuance. ### Configuration The `consent` property on an application controls whether users see a consent screen: - **`required`** — Users must approve before the application can access resources on their behalf. This is the default. - **`implicit`** — Users are not shown a consent screen; access is granted automatically. Privately registered applications remember consent across sessions. Publicly registered applications require consent each session, regardless of the `consent` property. This property is configured per-application in [Console](/admin/index.md) or via the [Terraform provider](https://registry.terraform.io/providers/keycardai/keycard/latest/docs).