Applications

Applications are software that access resources, 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 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.

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).

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).

Dependencies

Applications may have dependencies on resources.

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. 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.