The OIDC ID Token Trust Provider is Aembit’s solution for authenticating workloads using standard OIDC ID tokens. It validates incoming tokens against specific issuer, audience, and subject claims, giving you maximum flexibility to integrate with virtually any OIDC-compliant identity provider for secure, token-based workload access.
Benefits
Section titled “Benefits”By supporting the open OIDC standard, Aembit provides you with maximum flexibility and the following benefits:
Support for Any OIDC Provider - Connect to any identity provider compliant with the OIDC standard.
Reduced Static Credentials - Replace static credentials with short-lived OIDC tokens for more workloads.
Standardized Integration - Avoid custom development for new tools that support OIDC.
Simplified Operations - Apply a single authentication pattern for all OIDC-enabled workloads.
Match rules
Section titled “Match rules”The following table describes the match rules available for the OIDC ID Token Trust Provider:
| Rule\Claim | Description |
|---|---|
Audience (aud) | Identifies who the token is for. It specifies the intended recipient, ensuring a token created for one purpose isn’t misused for another. This helps prevent token replay attacks. Example: aembit-prod-api-access |
Issuer (iss) | Identifies who issued the token. It’s the URL of the identity provider system (such as Okta, GitLab, Jenkins) that you are trusting. This verifies the token came from the correct source. Example: https://identity-provider.my-company.com |
Subject (sub) | Identifies what or who the token is about. It’s a unique, case-sensitive string that represents the specific principal (a workload, service, or service account) Aembit is to authenticate. Example: workload-id-98765 or user-id-xyz-123 |
Attestation methods
Section titled “Attestation methods”The following table describes the attestation methods available for the OIDC ID Token Trust Provider:
| Attestation Method | Description |
|---|---|
| OIDC Discovery | Aembit uses this address to automatically find the provider’s configuration and locate its public keys. Use this for standard OIDC providers where you want to simplify configuration to a single URL. You must enter the main URL of the identity provider (like https://gitlab.com). |
| Symmetric Key | A single shared secret key. Your OIDC provider uses this key to sign tokens, and Aembit uses the same key to validate them. Symmetric algorithms like HS256 use this method. Use this attestation method for closed systems or legacy services where using a shared secret is preferred over public key cryptography. You must enter a shared secret key that’s Base64 encoded. |
| Upload JWKS | This is a static, point-in-time snapshot of your provider’s JSON Web Key Set (JWKS), which contains their public signing keys. Use this for any provider that exposes a public JWKS endpoint. This is what enables automatic key rotation for you. You must paste the entire JSON content of the provider’s JWKS into this field. |
| Upload Public Key | Your provider’s public key file (such as .pem or .cer). Use this for providers in private or air-gapped networks that don’t expose a public JWKS endpoint. You must paste the text content of a single public key, typically in PEM format. The Thumbprint is a unique, short identifier for that key that Aembit automatically calculates and displays for verification. |
How the OIDC ID Token Trust Provider works
Section titled “How the OIDC ID Token Trust Provider works”The authentication process involves a clear sequence of actions performed by your workload and by Aembit.
-
First, your workload requests an OIDC ID token from its identity provider (such as GitLab, Jenkins). The workload then presents this token to Aembit to prove its identity.
-
Next, Aembit validates the token’s signature. Using the configured Attestation Method, Aembit retrieves the provider’s public key and verifies that the signature is authentic. If the signature is invalid, Aembit rejects the request.
-
If the signature is valid, Aembit then validates the token’s claims. Aembit compares the issuer, audience, and subject claims within the token against the Match Rules you configured.
-
If the signature and all claims are valid, Aembit authenticates the workload and applies the relevant access policies. If any check fails, Aembit denies the request.