Skip to main content
OAuth Applications let you register an outside platform or service as an OAuth 2.0 client so it can act in Infisical on behalf of one of your users rather than as a shared service account. The client never sees the user’s password or session, every action is attributed to the real person, and the access it gets is bounded by that person’s own permissions. An OAuth application obtains its tokens through one of two flows, chosen when you register it:

Authorization code

The user approves the application on an Infisical consent screen in their browser. Best for a platform integrating with Infisical as an external auth provider, such as one where infisical run fetches secrets with the developer’s own permissions.

Token exchange

Trusted middleware you run presents a user’s token from your identity provider and receives an Infisical token for that same user. Best for MCP servers, internal developer portals, and API gateways that have no browser to redirect through.

​
Choosing a flow

​
Managing applications

OAuth applications live at the organization level, under Organization Settings → OAuth Applications. Managing them needs permission to manage OAuth applications; token exchange additionally needs permission to manage SSO. Access token lifetime is the shortest of the application’s access token lifetime (1 day by default), your organization’s session length, and the instance default of 10 days. The application’s own value is a ceiling, not an override: it can shorten a token’s life but never extend it past what the organization allows.

​
What a delegated token can never do

It cannot change anything under Administration, at either the organization or the project level. Creating, updating and deleting there stay with a person signed in to the dashboard:
  • Access control: members, groups, machine identities, roles, and additional privileges
  • Usage and billing
  • Audit log streams
  • Organization settings: SSO and provisioning, networking, encryption, project templates, sub-organizations, OAuth applications, and workflow integrations
  • Project settings: general settings, environments, tags, policies, webhooks, and encryption
It cannot manage the authorizing user’s account. Password, MFA, session, TOTP, and notification endpoints reject it outright, so an integration can never take over the account behind it. It cannot create an organization or change instance admin settings. Both sit outside the organization the delegation was issued for, so neither is narrowed by it.

​
Revoking access

Deleting an application immediately revokes every token it issued, in both flows. The other levers differ, most notably client secret rotation, which cuts off existing tokens on a token exchange application but not on an authorization code one. See revoking authorization code access and revoking token exchange access.