> ## Documentation Index > Fetch the complete documentation index at: https://docs.forge.ai/llms.txt > Use this file to discover all available pages before exploring further. # Gateway authentication > Authentication, identity, and access requirements for Forge LLM Gateway clients. The LLM Gateway accepts gateway keys and supported interactive organization sign-in. Both methods resolve to an organization and access profile before Forge checks models, policies, and budgets. | Method | Request credential | Identity and access | | - | - | - | | Gateway key | Gateway key in `Authorization: Bearer` or the client's supported API-key header | The key's subject and assigned access profile. | | Organization sign-in | OAuth access token in `Authorization: Bearer` | The signed-in person's current Forge membership, directory identity, and managed-access assignment. | | Verified attribution with a gateway key | Gateway key plus `X-Forge-Identity-JWT` | The key authenticates the client. A separately configured JWT verifier validates the end-user claims. | A customer IdP token is not automatically a gateway credential. Use the organization sign-in settings shown by Forge for supported interactive clients. Use a configured attribution verifier when an application sends an IdP token alongside its gateway key. ## Create and rotate a gateway key 1. In **Gateway**, configure a provider and an active access profile with the intended routes and model allowlist. 2. Create a gateway key for that profile. Set its subject and limits for the application or workload that will use it. 3. Copy the key when it is shown and store it in the application's secret manager. Provider API keys stay in the provider connection; do not give clients the upstream provider credential. 4. Test model discovery and a small inference request with the same key. 5. When rotating, install and test the replacement key before revoking the old key. A revoked key must stop authorizing new requests. Organization sign-in uses a person's access token instead of this key. Never put an access token or gateway key in a distributable managed setup file. ## Interactive sign-in settings **Gateway → Connect an app → Connection details and manual setup** shows the values for the selected application and environment. | Setting | Meaning | | - | - | | Gateway URL | Forge inference endpoint. Some clients append `/v1` themselves. | | Issuer URL | Forge's organization sign-in issuer. | | Client ID | Registered public OAuth client for the selected application. | | Scopes | `openid profile email offline_access`. | | Bearer token | Access token. An ID token is not an inference credential. | | Callback URL | Exact registered application callback. Claude Desktop uses `http://127.0.0.1:53180/callback`. | | Resource | Gateway audience, when Forge includes it in the connection details. | Supported clients use the authorization-code flow with PKCE. The setup file contains public connection settings and no shared employee secret. Each person completes their own sign-in. Refresh behavior belongs to the client and issuer. Forge verifies the token signature, issuer, expiration, audience, registered client, and selected organization. Tokens issued for another API or environment do not grant inference access. ## Organization and directory identity Interactive inference requires all of the following: * The selected sign-in organization is linked to the Forge organization. * The signed-in account is linked to an existing Forge user and organization membership. * The membership is linked to an active directory identity. * The person's managed-access identity is active. * The effective assignment resolves to an active access profile. Directory collection and enterprise SSO are separate setup tasks. Connecting the [Entra directory integration](/integrations/entra) or [Okta directory integration](/integrations/okta) does not by itself configure organization sign-in. Your administrator must complete the organization's sign-in setup and confirm the user linkage. Forge uses its current directory membership for group access. Arbitrary group claims in a client's token do not create department assignments. ## Assignment precedence Managed access selects an explicit person assignment first, then one matching directory-group assignment, then the organization default. Multiple matching group assignments are ambiguous and block access. An unusable selected assignment does not fall back to a less specific assignment. Use **Manage access** to resolve overlapping groups or assign an explicit profile to the person. The access profile still determines allowed models, providers, and request types. A completed sign-in does not bypass those limits or an exhausted budget. ## Gateway-key attribution An application can send a verified end-user token in `X-Forge-Identity-JWT` while authenticating with its gateway key. Configure the token issuer, audience, JWKS URL, and claim mappings before relying on that identity. Unverified identity headers do not establish user or group permission. This attribution method is separate from the interactive access token used by Claude Desktop and other supported organization-sign-in clients. ## Diagnose a denied request | Result | Check | | - | - | | Sign-in completes, but inference is unauthorized | Access-token type, selected organization, user linkage, active directory identity, and effective assignment. | | Model is unavailable | Access profile, requested model, eligible protocol route, and provider configuration. | | Budget rejects the request | The applicable person, group, profile, or key budget and its current window. | | Organization sign-in is unavailable | Forge's issuer and registered application configuration. Contact your Forge administrator. | See [Connect apps to Forge](/secure/connect-apps-to-forge) for client setup and [Claude Desktop with Forge](/secure/claude-desktop-with-forge) for deployment. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.