> ## 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.

# Credentials and identity

> Authenticate callers to Forge and broker the right destination credential without exposing it.

Resource access has two separate authentication boundaries:

1. The caller proves a Forge user or service-account identity to the Resource
   Gateway.
2. After policy and approval, the Gateway obtains the destination credential
   assigned to that identity and authenticates upstream.

The caller never receives the destination secret, and the destination never
receives the caller's Forge credential.

## Caller identity

Automatic routing uses the identity and device assertion established by Forge
on the managed endpoint. Direct human access uses a short-lived credential
created from the Resource page. Direct non-interactive access uses an active
Forge service account with the `resources:connect` scope.

Resource Policy can scope a decision to users, groups, service accounts,
devices, Resources, and a proven calling process when available. Forge does not
infer an Agent identity solely from a process observation.

## Destination credential methods

| Method | Protocols | Secret or identity used by the Gateway |
| - | - | - |
| Username and password | PostgreSQL, MySQL | Protected database username and password |
| Redis ACL credential | Redis | Protected Redis ACL username and password |
| Bearer token | HTTP/HTTPS | Protected token injected after policy |
| Custom header | HTTP/HTTPS | Protected value injected into one configured header |
| AWS IAM temporary access | PostgreSQL, MySQL | Gateway workload identity and optional exact role; password generated only when needed |
| OAuth temporary access | HTTP/HTTPS | Protected client secret exchanged for an expiry-bound bearer token |
| Identity token exchange | HTTP/HTTPS | Caller-bound Forge token exchanged for an upstream bearer token; no upstream secret is stored |

Credential choices are limited to methods the selected protocol can actually
use.

## Assign a credential

Open **Policies**, select **Resources**, and open a configured Resource. The
**Credentials** section is directly below its connection settings. It shows
the destination identity, assignment, credential type, and last use without
revealing stored secrets.

A credential can be the Resource default or be assigned to users, groups, and
service accounts. Selection is deterministic:

1. Exact service-account assignment
2. Exact user assignment
3. One unambiguous matching group assignment
4. Default credential

If more than one matching group selects different credentials, or a referenced
identity cannot be resolved exactly, Forge rejects the connection. Disabled
and cross-organization identities are never eligible.

When a Resource has no credentials, Forge rejects connections instead of
passing caller credentials through to the destination. The default is an
explicit credential used for otherwise unmatched callers, not anonymous or
pass-through access.

Use group assignments for ordinary team access, exact user or service-account
assignments for exceptions, and a default only when every otherwise unmatched
caller should share the same destination identity.

## Temporary AWS database access

For RDS or Aurora PostgreSQL and MySQL:

1. Enable IAM database authentication on the destination.
2. Give the Gateway workload identity `rds-db:connect` for the intended
   database user, or configure one exact role for it to assume.
3. Create an **AWS IAM temporary access** credential with the destination
   username and AWS Region.
4. Optionally enter the exact role ARN. The workload identity then also needs
   `sts:AssumeRole`, and the role trust policy must admit it.

The Gateway generates the temporary database password only after policy and
approval. Static AWS access keys are neither needed nor recommended.

## Temporary HTTP access

Use **OAuth temporary access** for OAuth 2.0 client credentials. Enter an HTTPS
token endpoint, client ID, client secret, and optional scopes or audience. The
Gateway uses HTTP Basic client authentication, caches the returned access token
only until shortly before expiry, and injects it after policy allows the
request.

Use **Identity token exchange** when the provider accepts OAuth 2.0 token
exchange and should retain the individual Forge caller identity. Configure the
provider to trust Forge's issuer and Resource Gateway audience. Each caller's
upstream token is cached separately and only until shortly before expiry.

Token endpoint redirects, IP-address endpoints, and unencrypted token endpoints
are rejected.

## Secret handling and rotation

Forge never returns a saved destination secret after creation. Replacing a
secret applies to subsequent connections without changing the Resource or its
policies. A credential connection test runs from the assigned Gateway and
returns only success or a bounded error.

When using Terraform 1.11 or newer, pass `secret` as a write-only ephemeral
value and increase `secret_version` to rotate it. Keep the narrow
`resource_credentials:write` scope separate from ordinary policy automation
when possible. See [Terraform](/developer/terraform/overview) for examples.

See [Identity model](/resources/identity-model) for the distinction between
directory users, agents, provider identities, and Forge service accounts.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.