Skip to main content
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

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 for examples. See Identity model for the distinction between directory users, agents, provider identities, and Forge service accounts.