---
title: Universal Auth
description: "Learn how to authenticate to Infisical from any platform or environment."
---

**Universal Auth** is a platform-agnostic authentication method that can be configured for a [machine identity](/documentation/platform/identities/machine-identities) to authenticate from any platform/environment using a Client ID and Client Secret.
This authentication method supports setting token periods, which can help [overcome secret zero](#solving-secret-zero-with-periodic-tokens).

## Diagram

The following sequence diagram illustrates the Universal Auth workflow for authenticating clients with Infisical.

```mermaid
sequenceDiagram
  participant Client as Client
  participant Infis as Infisical

  Note over Client,Infis: Step 1: Login Operation
  Client->>Infis: Send Client ID and Client Secret

  Note over Infis: Step 2: Client ID and Client Secret validation
  Infis->>Client: Return short-lived access token

  Note over Client,Infis: Step 3: Access Infisical API with Token
  Client->>Infis: Make authenticated requests using the short-lived access token
```

## Concept

In this method, Infisical authenticates a client by verifying the credentials issued for it at the `/api/v1/auth/universal-auth/login` endpoint. If successful,
then Infisical returns a short-lived access token that can be used to make authenticated requests to the Infisical API.

To be more specific:

1. The client submits a **Client ID** and **Client Secret** to Infisical at the `/api/v1/auth/universal-auth/login` endpoint.
2. Infisical verifies the credential pair.
3. If all is well, Infisical returns a short-lived access token that the client can use to make authenticated requests to the Infisical API.

## Guide

In the following steps, we explore how to create and use identities for your workloads and applications to access the Infisical API
using the Universal Auth authentication method.

<Steps>
  <Step title="Creating an identity">
    To create an identity, head to your Organization Settings > Access Control > Identities and press **Create identity**.

    ![identities organization](/images/platform/identities/identities-org.png)

    When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.

    ![identities organization create](/images/platform/identities/identities-org-create.png)

    Now input a few details for your new identity. Here's some guidance for each field:

    - Name (required): A friendly name for the identity.
    - Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.

    Once you've created an identity, you'll be redirected to a page where you can manage the identity.

    ![identities page](/images/platform/identities/identities-page.png)

    Once you've created an identity, you'll be prompted to configure the **Universal Auth** authentication method for it.

    By default, the identity has been configured with Universal Auth. If you wish, you can edit the Universal Auth configuration
    details by pressing to edit the **Authentication** section.

    Here's some guidance on each field:

    **Configuration Tab**

    ![identities organization create universal auth method 1](/images/platform/identities/identities-org-create-universal-auth-method-1.png)

    - Access Token TTL (default is `2592000` equivalent to 30 days): The lifetime for an access token in seconds. This value will be referenced at renewal time.
    - Access Token Max TTL (default is `2592000`  equivalent to 30 days): The maximum lifetime for an access token in seconds. This value will be referenced at renewal time.
    - Access Token Max Number of Uses (default is `0`): The maximum number of times that an access token can be used; a value of `0` implies infinite number of uses.
    - Access Token Period (optional, default is `0`): If set, the access token becomes a renewable, non-expiring token for the specified period (in seconds). TTL and Max TTL are ignored when this is set. This is ideal for "secret zero" scenarios, where a workload needs to bootstrap itself securely without hard-coded static secrets.

    **Lockout Tab**

    ![identities organization create universal auth method 2](/images/platform/identities/identities-org-create-universal-auth-method-2.png)

    - Lockout (enabled by default): The lockout feature will temporarily block login attempts after X consecutive login failures.
    - Lockout Threshold (default is `3`): The amount of times login must fail before locking the identity auth method.
    - Lockout Duration (default is `5 minutes`): How long an identity auth method lockout lasts.
    - Lockout Counter Reset (default is `30 seconds`): How long to wait from the most recent failed login until resetting the lockout counter.

    **Advanced Tab**

    ![identities organization create universal auth method 3](/images/platform/identities/identities-org-create-universal-auth-method-3.png)

    - Client Secret Trusted IPs: The IPs or CIDR ranges that the **Client Secret** can be used from together with the **Client ID** to get back an access token. By default, **Client Secrets** are given the `0.0.0.0/0`, allowing usage from any network address.
    - Access Token Trusted IPs: The IPs or CIDR ranges that access tokens can be used from. By default, each token is given the `0.0.0.0/0`, allowing usage from any network address.

    <Warning>
    Restricting **Client Secret** and access token usage to specific trusted IPs is a paid feature.

    If you're using Infisical Cloud, then it is available under the Pro Tier. If you're self-hosting Infisical, then you should contact sales@infisical.com to purchase an enterprise license to use it.
    </Warning>

  </Step>
  <Step title="Creating a Client Secret">
    In order to use the identity, you'll need the non-sensitive **Client ID**
    of the identity and a **Client Secret** for it; you can think of these credentials akin to a username
    and password used to authenticate with the Infisical API.
    With that, press **Create Client Secret**.

    ![identities client secret create](/images/platform/identities/identities-universal-auth-create-1.png)
    ![identities client secret create](/images/platform/identities/identities-universal-auth-create-2.png)
    ![identities client secret create](/images/platform/identities/identities-universal-auth-create-3.png)

    Feel free to input any (optional) details for the **Client Secret** configuration:

    - Description: A description for the **Client Secret**.
    - TTL (default is `0`): The time-to-live for the **Client Secret**. By default, the TTL will be set to 0 which implies that the **Client Secret** will never expire; a value of `0` implies an infinite lifetime.
    - Max Number of Uses (default is `0`): The maximum number of times that the **Client Secret** can be used together with the **Client ID** to get back an access token; a value of `0` implies infinite number of uses.

  </Step>
  <Step title="Adding an identity to a project">
    To enable the identity to access project-level resources such as secrets within a specific project, you should add it to that project.

    To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**.

    Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to.

    ![identities project](/images/platform/identities/identities-project.png)

    ![identities project create](/images/platform/identities/identities-project-create.png)

  </Step>
  <Step title="Accessing the Infisical API with the identity">
    To access the Infisical API as the identity, you should first perform a login operation
    that is to exchange the **Client ID** and **Client Secret** of the identity for an access token
    by making a request to the `/api/v1/auth/universal-auth/login` endpoint.

    <Tip>
      Choose the correct base URL based on your region:

      - For Infisical Cloud US users: `https://app.infisical.com`
      - For Infisical Cloud EU users: `https://eu.infisical.com`
    </Tip>

    #### Sample request

    ```bash Request
    curl --location --request POST 'https://app.infisical.com/api/v1/auth/universal-auth/login' \
      --header 'Content-Type: application/x-www-form-urlencoded' \
      --data-urlencode 'clientId=...' \
      --data-urlencode 'clientSecret=...'
    ```

    #### Sample response

    ```bash Response
    {
      "accessToken": "...",
      "expiresIn": 7200,
      "accessTokenMaxTTL": 43244
      "tokenType": "Bearer"
    }
    ```

    Next, you can use the access token to authenticate with the [Infisical API](/api-reference/overview/introduction)

    <Note>
      Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
      the default TTL is `7200` seconds which can be adjusted in the Universal Auth configuration.

      If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
      a new access token should be obtained by performing another login operation.
    </Note>

  </Step>
</Steps>

## Solving Secret Zero with Periodic Tokens

In many automated, cloud-native, or ephemeral environments (such as VMs, containers, or serverless functions), it is often unsafe or impractical to hard-code long-lived credentials for bootstrapping access to secrets management systems. The "secret zero" problem refers to the challenge of securely providing a workload with its initial credential, without manual intervention or static secrets that could be leaked or reused. Periodic tokens in Universal Auth are designed to solve this problem by enabling secure, automated bootstrapping and ongoing access renewal, even in dynamic or short-lived environments.

A common challenge in cloud-native and automated environments is the "secret zero" problem: how to securely bootstrap a workload (such as a VM, container, or serverless function) with its first credential, without hard-coding static secrets or requiring manual intervention.

**Periodic tokens** in Universal Auth solve this by allowing you to issue an access token that can be continuously renewed by your workload before it expires (i.e., a client-initiated rotation mechanism):

- When you set the **Access Token Period** in the Universal Auth configuration, the issued access token can be renewed by your workload for the specified period (in seconds).
- The token can be renewed any number of times, each time for the same period, with no maximum lifetime (unless you set a use limit).
- As long as the token is renewed before its period expires, it remains valid, so you do not need to re-issue static credentials.
- TTL and Max TTL are ignored when Access Token Period is set.

### Example: Bootstrapping with a Periodic Token

1. Configure Universal Auth for your identity and set **Access Token Period** (e.g., `3600` for 1 hour).
2. For improved security, configure the Client Secret with a low number of uses (e.g., `1`) or a short TTL. This ensures that after the initial login, the Client Secret cannot be reused, and any disruption in token renewal will require manual intervention.
3. Deploy your workload with the **Client Secret** and **Client ID**.
4. The workload authenticates with Infisical using the Client Secret and Client ID to obtain the initial access token (JWT).
5. The workload uses the access token to authenticate and continuously renews it before expiration:

```bash
curl --location --request POST 'https://app.infisical.com/api/v1/auth/universal-auth/renew' \
  --header 'Authorization: Bearer <accessToken>'
```

This approach allows your workload to securely bootstrap and maintain access to Infisical without hard-coded secrets, solving the secret zero problem.

**FAQ**

<AccordionGroup>
  <Accordion title="Why is the Infisical API rejecting my identity credentials?">
    There are a few reasons for why this might happen:
    - The client secret or access token has expired.
    - The identity is insufficiently permissioned to interact with the resources you wish to access.
    - The client secret/access token is being used from an untrusted IP.
  </Accordion>
  <Accordion title="What is access token renewal and TTL/Max TTL?">
    A identity access token can have a time-to-live (TTL) or incremental lifetime after which it expires.

    In certain cases, you may want to extend the lifespan of an access token; to do so, you must set a max TTL parameter.

    A token can be renewed any number of times where each call to renew it can extend the token's lifetime by increments of the access token's TTL.
    Regardless of how frequently an access token is renewed, its lifespan remains bound to the maximum TTL determined at its creation.
  </Accordion>
  <Accordion title="How do I reset a lockout?">
      You can reset (remove) all lockouts for an identity auth method by clicking into the auth method and pressing **Reset All Lockouts**.

      ![ua reset lockouts](/images/platform/identities/ua-reset-lockouts.png)
  </Accordion>
</AccordionGroup>
