awatertrevi/infisical
1
0
Fork 0
mirror of https://github.com/awatertrevi/infisical.git synced 2026-09-22 13:39:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

misc: doc improvments

Browse Source
This commit is contained in:
Sheen Capadngan
2025-05-29 03:32:19 +08:00
parent d08510ebe4
commit db9a1726c2
2 changed files with 13 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
backend/src/lib/api-docs/constants.ts
View File

@@ -148,7 +148,8 @@ export const UNIVERSAL_AUTH = {
"The maximum lifetime for an access token in seconds. This value will be referenced at renewal time.",
accessTokenNumUsesLimit:
"The maximum number of times that an access token can be used; a value of 0 implies infinite number of uses.",
accessTokenPeriod: "The period for an access token in seconds. This value will be referenced at renewal time."
accessTokenPeriod:
"The period for an access token in seconds. This value will be referenced at renewal time. Default value is 0."
},
RETRIEVE: {
identityId: "The ID of the identity to retrieve the auth method for."

17
docs/documentation/platform/identities/universal-auth.mdx
View File

@@ -74,7 +74,7 @@ using the Universal Auth authentication method.
- 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.
- 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.
- Access Token Period (optional): 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.
- 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.
<Warning>
Restricting **Client Secret** and access token usage to specific trusted IPs is a paid feature.
@@ -159,20 +159,24 @@ using the Universal Auth authentication method.
## 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 a renewable, non-expiring access token to your workload:
**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 becomes renewable for the specified period (in seconds).
- 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 and does not require re-issuing static credentials.
- 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. Deploy your workload with the initial access token.
3. Your workload uses the access token to authenticate and can renew it before expiration:
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' \
@@ -197,5 +201,6 @@ This approach allows your workload to securely bootstrap and maintain access to
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>
</AccordionGroup>