Skip to content
DOCS
User Guide CLI Guide API Guide

About Credential Providers

Credential Providers bridge the gap between authorized Client Workloads and the authentication requirements of target Server Workloads. They obtain the specific access credentials—such as API keys, OAuth tokens, temporary cloud credentials, or signed tokens—that Client Workloads need to authenticate successfully to Server Workloads.

Credential Providers function as an abstraction layer, decoupling Client Workloads from the complex authentication mechanisms required by diverse Server Workloads. Whether a target service requires AWS federation, OAuth 2.0 flows, JWT validation, or basic API keys, the Client Workload doesn’t need to implement the corresponding protocol logic.

Aembit invokes Credential Providers only after rigorous security checks: first, Trust Providers verify the Client Workload’s identity through attestation, and second, all Access Conditions must pass. This ensures that credentials are only dispensed to trusted and authorized requesters.

Start configuring Credential Providers See Credential Providers in the User Guide
→

How Credential Providers work

Section titled “How Credential Providers work”

The following steps outline how Aembit uses Credential Providers during the authorization process:

  1. Request Access - A Client Workload initiates a request to access a Server Workload, which Aembit Edge intercepts.

  2. Identity and Context Verification - Aembit first verifies the workload’s identity through Trust Providers and evaluates all Access Conditions.

  3. Credential Provider Selection - Once all security checks pass, Aembit selects the appropriate Credential Provider based on the matched Access Policy configuration.

  4. Backend Interaction - The Credential Provider interacts with the relevant backend system (AWS Security Token Service (STS), OAuth server, internal vault, etc.) to obtain the required access credential.

  5. Credential Acquisition - The provider generates, retrieves, or manages the specific credential format needed by the target Server Workload.

  6. Secure Transmission - Aembit Cloud securely transmits the obtained credential back to the Aembit Edge component that intercepted the original request.

  7. Credential Injection - Aembit Edge modifies the original client request by injecting the credential (typically into HTTP headers) before forwarding it to the Server Workload.

The following diagram illustrates this process:

Diagram

Supported provider types

Section titled “Supported provider types”

Aembit offers multiple types of Credential Providers to accommodate the varied authentication mechanisms used by modern and legacy Server Workloads:

Local providers

Section titled “Local providers”

Local Credential Providers store and manage credential values within the Aembit platform itself. When invoked, Aembit retrieves the pre-configured secret from its internal secure storage.

Supported local types:

  • API Key - For services authenticating via static API keys.
  • Username & Password - For services using traditional username/password authentication.

Common use cases:

  • Legacy systems that don’t support modern authentication methods
  • Basic APIs requiring static key-based authentication
  • Bridging authentication for systems during modernization transitions

Remote providers

Section titled “Remote providers”

Remote Credential Providers interact with external systems to dynamically generate or retrieve access credentials on behalf of Client Workloads. Aembit acts as a broker to these external credential authorities.

Cloud provider federations:

Standards-based authentication:

Platform-specific providers:

Common use cases:

  • Accessing cloud services with temporary, scoped credentials
  • Integrating with modern SaaS applications using OAuth 2.0
  • Connecting to enterprise secrets management systems
  • Authenticating to CI/CD platforms and development tools

Advanced configurations

Section titled “Advanced configurations”

Aembit supports sophisticated configurations for complex scenarios:

Benefits of using Credential Providers

Section titled “Benefits of using Credential Providers”

  • Security Abstraction - Shields Client Workloads from complex authentication protocols, reducing the risk of implementation errors and credential exposure.

  • Dynamic Credential Management - Facilitates the use of short-lived, ephemeral credentials wherever possible, reducing the risk of credential compromise.

  • Simplified Development - Eliminates the need for developers to implement and maintain diverse authentication mechanisms in their applications.

  • Centralized Control - Provides a single point of configuration and management for access credentials across heterogeneous environments.

  • Zero-Touch Authentication - Enables “secretless” architectures where Client Workloads don’t need to handle credentials directly.

  • Policy-Driven Access - Ensures credentials are only issued after identity verification and policy compliance, enforcing least privilege access.

  • Operational Flexibility - Allows authentication method changes without modifying Client Workload code, supporting system modernization efforts.

  • Comprehensive Coverage - Supports both modern federated authentication and legacy systems, enabling unified access management across diverse infrastructures.