> ## Documentation Index > Fetch the complete documentation index at: https://infisical.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # OAuth applications > Let external platforms and services act in Infisical on behalf of your users. **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: 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. 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 | | Authorization code | Token exchange | | --------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------- | | Who approves the delegation | Each user, on a consent screen | An organization admin, once at registration | | Needs a browser redirect | Yes | No | | What the token can do | Only the requested scopes, intersected with the user's permissions | The user's full effective permissions, read-only for administration | | Refresh tokens | Yes | No, exchange again instead | | Prerequisites | Registered redirect URIs | An active OIDC SSO configuration for the organization | ## 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](/docs/documentation/platform/oauth-applications/authorization-code#revoking-access) and [revoking token exchange access](/docs/documentation/platform/oauth-applications/token-exchange#revoking-access).