Application Credentials

An Application Credential authenticates a downstream Application to Axec. It does not authenticate the Application to an upstream Connector.

Applications, clients, and credentials

A platform-managed Application can own multiple OAuth clients. Each client has its own client ID and authentication configuration.

These terms describe different things:

• Application: The software identity in Axec.
• OAuth client: The configuration that the software uses to request authorization.
• Application Credential: The secret or private-key proof that a Private client uses to authenticate.

A client ID identifies a specific OAuth client. It is not a secret and does not grant access by itself.

Example: A Support Agent has a browser interface and a scheduled background worker. Both belong to the same Application but use separate OAuth clients. The browser uses a Public client. The worker uses a Private client.

Client types

The client type describes how the software authenticates to Axec. OAuth 2.0 (RFC 6749) defines both types.

A Public client does not use a client secret. This configuration suits browser applications and distributed desktop tools, where a shared secret cannot reliably remain confidential.

A Private client runs in an environment that can protect a secret or private key. It uses that credential to prove its identity to Axec.

OAuth calls Private clients confidential clients. Axec APIs use public and confidential for these types.

Client type and registration method are separate. An administrator can create a Public client, and a URL-based client can be Public or Private.

Public clients and PKCE

A Public client requests delegated access using Authorization Code (RFC 6749 §4.1). It protects the code exchange with S256 PKCE (RFC 7636), or Proof Key for Code Exchange.

PKCE protects the authorization-code exchange:

1. The client creates a temporary verifier for the authorization attempt.
2. The client sends a challenge derived from that verifier when it starts authorization.
3. The client supplies the verifier when it exchanges the authorization code for a token.
4. Axec checks that the verifier matches the original challenge.

This prevents someone who obtains the authorization code from redeeming it without the matching verifier.

The verifier is temporary proof for that authorization attempt. It is not a reusable client secret and does not make the client Private.

Example: Alex asks a browser-based assistant to read tickets. The assistant starts authorization with its client ID and a PKCE challenge. After Alex completes authorization, the assistant exchanges the code using the matching verifier.

Public clients currently support delegated access only. They cannot request autonomous access through Client Credentials.

Private clients: client ID and secret

A Private client can authenticate with an Axec-issued client ID and client secret. This mechanism is OAuth client authentication with client_secret_basic (RFC 6749 §2.3.1).

The client ID tells Axec which client is calling. The secret proves that the caller possesses the credential for that client.

Axec returns a newly issued secret once and stores only its hash. The calling software must keep the plaintext secret in protected storage.

The client secret authenticates the software to Axec. It is not the User’s password, an upstream API key, or permission to access every Connector.

Example: A scheduled Support Agent stores its client secret in the backend’s secret manager. It sends the client ID and secret to Axec when requesting an autonomous access token.

Axec still checks the Application’s dependencies and the eligible upstream credential path. Valid client authentication alone does not grant upstream access.

URL credentials

A client can use a hosted metadata URL as its client ID instead of an Axec-issued identifier. The URL points to a Client ID Metadata Document (CIMD) that describes the client’s OAuth configuration.

A Private URL client keeps a private key and authenticates with a signed assertion using private_key_jwt (RFC 7523). Its metadata publishes public-key information.

Axec reads the published public keys and checks the assertion’s signature. Axec does not need the private key or a shared client secret.

Example: A worker uses https://agent.example.com/oauth-client.json as its client ID. Its metadata publishes public-key information. The worker signs a fresh assertion with the corresponding private key when it authenticates to Axec.

The URL is an identifier, not a secret. Knowing the URL does not authenticate a Private client. The caller must provide valid signed proof.

A Public URL client uses the same URL-based identification model without client authentication. Its metadata sets token_endpoint_auth_method to none, and delegated authorization requires PKCE.

Example: A browser assistant publishes its client configuration at a metadata URL. It uses that URL as its client ID and protects authorization-code redemption with PKCE.

Using a metadata URL does not automatically make an Application dynamically registered. A platform-managed client can also use a URL credential.

Credential kinds

Kind	Client type	Standard	Material
client_secret	Private	RFC 6749 §2.3.1	A secret hash and a safe fingerprint
private_key_jwt	Private	RFC 7523	Public-key material and a safe fingerprint
public_pkce	Public	RFC 7636	No secret. Authorization requires PKCE S256.

An administrator can create either Private kind. A Private URL client uses private_key_jwt. A Public client or Public URL client uses public_pkce. Dynamic Client Registration and Client ID Metadata Documents establish Public clients.

Exact credential binding

Credentials have active, revoked, or expired status. Axec retains credential history.

Axec binds Grants, authorization artifacts, and tokens to the exact identity of the credential used.

Credential rotation changes authority. It does not just change a secret value:

old credential revoked
  -> replacement credential receives a new identity
  -> authority bound to the old identity stops passing live checks

Keep credential roles separate

Axec handles several kinds of credentials, but they are not interchangeable:

• An Application Credential proves which downstream Application calls Axec.
• A Connection holds one User’s upstream account authority.
• A workspace Vaulted Credential supplies workspace-owned upstream authority.
• A Connector OAuth client credential authenticates Axec itself to an upstream authorization server.
• A Service Account exchanges its credential for a management API token.

See live authority enforcement for how credential restriction affects issued tokens.

Related standards

Application authentication and its OAuth protocol behavior follow these open standards:

Standard	Reference
OAuth 2.0 Authorization Framework	RFC 6749
Authorization Code and Client Credentials grants	RFC 6749 §4
Client authentication with client_secret_basic	RFC 6749 §2.3.1
Proof Key for Code Exchange (PKCE)	RFC 7636
JWT client authentication (private_key_jwt)	RFC 7523
JSON Web Token (JWT)	RFC 7519
JSON Web Key (JWK)	RFC 7517
JSON Web Algorithms (JWA), RS256	RFC 7518
Dynamic Client Registration (DCR)	RFC 7591
Client ID Metadata Document (CIMD)	IETF draft
Authorization Server Metadata	RFC 8414
Protected Resource Metadata	RFC 9728
Resource Indicators (exact Resource audience)	RFC 8707