About the OIDC ID Token Credential Provider

The OIDC ID Token Credential Provider enables secure identity token generation and exchange with third-party services.

By leveraging Aembit’s custom Identity Provider (IdP) capabilities, the OIDC ID Token Credential Provider generates JWT-formatted tokens that you can use with different Workload Identity Federation (WIF) solutions.

The Credential Provider supports:

Custom claims configuration
Flexible signing algorithms
Integration with identity brokers (AWS STS, GCP WIF, Azure WIF, Vault, etc.)

See Create an OIDC ID Token Credential Provider to create one.

Common use cases

Cloud Provider Access: Securely access to AWS, GCP, or Azure resources using their respective WIF solutions.
Vault Integration: Authenticate with HashiCorp Vault using OIDC tokens.
Custom Service Authentication: Integrate with any service that supports OIDC/JWT authentication.

How the OIDC ID Token Credential Provider works

Token Generation: Aembit’s custom IdP generates JWT-formatted OIDC tokens and signs them using your Aembit Tenant-specific keys.
Client identification: Aembit identifies each IdP client configuration using an Aembit-specific Uniform Resource Name (URN) notation as its client_id (for example: aembit:useast2:1ed42e:identity:oidc-idtoken:2821c459-5541-4a59-9add-d69d5b3ae3db).

:::caution Custom claims

If you’re creating custom claims when configuring an OIDC ID Token Credential Provider, don’t use client_id as Aembit reserves the value to identify Client Workloads.

:::
Token Exchange: The Credential Provider requests tokens from Aembit’s IdP and then exchanges these tokens with external identity brokers to obtain service-specific credentials for the workload.

Configuration options

The following sections detail the configuration options you have for the OIDC ID Token Credential Provider:

Claims configuration

Aembit’s IdP supports dynamic token generation with the following capabilities:

Dynamic Claims - You can specify Claims at token request time, eliminating the need for pre-configuration.
Client Identification - Aembit identifies each IdP client (such as Aembit Cloud user, Agent Proxy, or Credential Provider-Workload association) using a unique client_id value.
Token Customization - Generated tokens follow configurations associated with the specified IdP client, including claims, scopes, and other parameters.

See the list of Common OIDC claims for more info.

Subject configuration options

The OIDC ID Token Credential Provider offers two methods for configuring the subject claim in OIDC ID tokens:

Dynamic subject - Aembit’s Credential Provider determines the subject value at runtime by evaluating runtime variables and the requesting workload’s identity. This allows Aembit to adapt to different callers, generating appropriate subject values for each.

Use dynamic subjects when you need the token’s subject to accurately reflect the identity of the calling entity, or when different workloads should have different subjects in their tokens.
Literal subject - You provide a fixed, predefined string that Aembit uses as the subject claim in all tokens the OIDC ID Token Credential Provider issues.

Use literal subjects when you’re integrating with a system that expects a specific, unchanging subject value, or when you want to abstract the actual identity of the calling entity.

Signing configuration

Aembit manages signing keys on a per-tenant basis and has the following characteristics:

uses the signature algorithm that you choose when setting up your IdP client; either RS256 (default) or ES256.
maintains different sets of keys for each associated signing algorithm.
makes all keys available via the public JSON Web Key Set (JWKS) interface.

Identity broker integration

The OIDC ID Token Credential Provider supports integration with different identity brokers through configurable options:

Endpoint Configuration:
- You specify the HTTP/S endpoint URL
- You configure custom headers as needed
Request Formatting:
- Aembit formats request bodies as JSON (with XML support planned for future releases)
Response Parsing:
- The Credential Provider parses JSON responses (with XML support planned for future releases)
- You can configure cache lifetime management

Implementation notes

You also have the option to manage OIDC ID Token Credential Providers using Terraform.
The Credential Provider builds on existing WIF Credential Provider capabilities.
Current JWKS endpoint implementation aligns with industry standards (AWS EKS, Google APIs, Okta, GitHub), which typically use RS256 algorithms.
Aembit recommends testing when using with identity brokers that may have specific algorithm requirements.

Common OIDC claims

The following table describes some common OIDC claims and how to configure them:

Claim	Description	Configuration
`iss`	Issuer - Identifies Aembit as the OIDC provider	Aembit automatically generates this based on your Aembit Tenant, but you can customize it to match external system requirements.
`sub`	Subject - Unique identifier for the workload	Configure as Dynamic (based on the workload’s identity) or Literal (a fixed value you specify).
`aud`	Audience - Intended recipient of the token	Enter the URI or identifier of your target service (for example, `https://sts.amazonaws.com` for AWS, `https://www.googleapis.com/oauth2/v4/token` for GCP).
`exp`	Expiration - When the token becomes invalid	Set the Lifetime in seconds (for example, `3600` for 1 hour).
`iat`	Issued At - Token creation time	Automatically set by Aembit when the token upon issuance.
`nbf`	Not Before - Token validity start time	Automatically set by Aembit when the token upon issuance.
`jti`	JWT ID - Unique token identifier	Automatically generated by Aembit to prevent replay attacks.
`<custom_claim>`	Custom arbitrary claims you can define.	Custom claim examples: `role`, `workload_metadata`, `custom_field`.

:::caution Using custom claims

If you’re creating custom claims when configuring an OIDC ID Token Credential Provider, don’t use client_id as Aembit reserves the value to identify Client Workloads.

:::