AuthFI Connect

One identity.
Every cloud.

Federate your people straight into the AWS, GCP, Azure & OCI console and CLI — mapped to real IAM roles, with short-lived credentials and one audit trail. Not traditional SSO into an app: this is identity, federated into the cloud itself.

Available on Pro and above. See pricing

Start free Read the docs

The mechanism

No standing keys. The cloud mints the credential.

Keyless cloud access is federation, not a key vault. AuthFI is an OpenID Connect identity provider; each cloud trusts its issuer and JWKS once. When a person needs access, AuthFI presents a signed OIDC token and the provider exchanges it — in AWS via sts:AssumeRoleWithWebIdentity, in GCP via Workload Identity Federation, in Azure via an OIDC federated credential, in OCI via token exchange — for that provider's own short-lived STS credential. The pattern is standardised as OAuth 2.0 Token Exchange (RFC 8693): trade a token you hold for a credential scoped to the role you're allowed to assume.

  • The problem it removes: long-lived AKIA… keys in CI, laptops and ~/.aws/credentials — the credential class behind most cloud breaches. There is nothing to leak, because nothing is stored.
  • Scoped by the provider: the trust policy on the IAM role decides what the token may assume. AuthFI proposes identity; the cloud's own IAM enforces authorization.
  • The payoff: no rotation jobs, no secrets-manager sprawl, no key-leak incident response — federation deletes the artifact instead of guarding it.
token-exchange.http
# AWS STS — exchange an OIDC token for short-lived creds
POST https://sts.amazonaws.com/
  ?Action=AssumeRoleWithWebIdentity
  &RoleArn=arn:aws:iam::…:role/developer
  &WebIdentityToken=eyJhbGciOiJSUzI1Ni␣…

# ↳ provider returns short-lived credentials
{
  "AccessKeyId": "ASIA…",
  "SecretAccessKey": "…",
  "SessionToken": "…",
  "Expiration": "2026-06-21T10:18:00Z"
}

AuthFI never holds a cloud key. It presents identity; STS returns a credential that expires on its own.

One click to any console

One identity. Every cloud.

Users click a cloud tile, get temporary credentials, access the console — no separate cloud passwords. The same binding works for the CLI: one AuthFI role resolves to a real IAM role in each of AWS, GCP, Azure and OCI, so a single group membership governs access across all four providers instead of four disconnected IAM consoles.

console.authfi.io/cloud-access
Your cloud accounts
Central role mapping — one AuthFI role maps to IAM roles across all four clouds
AuthFI roleAWSAWSGCPGCPAzureAzure
adminPowerUserAccessroles/editorContributor
developerS3ReadOnlyroles/viewerReader
devopsAdministratorAccessroles/ownerOwner
financeBillingViewAccessroles/billing.viewerBilling Reader

Federation, not a tile

It's not SSO into the "AWS app." It's your people, federated into the cloud.

Traditional SSO drops a user at an application's login and stops at the app door. Cloud access goes a layer deeper: it federates the identity into the cloud provider itself, so people land in the console — or get CLI credentials — already assumed into a real IAM role, with short-lived keys. No per-account SAML app to babysit, no static keys to rotate.

  • Traditional SSO: SAML or OIDC to an app's login. Useful — and AuthFI does full SAML 2.0 & OIDC SSO for every app you run.
  • Cloud access: federates straight into the provider — console and CLI, scoped to a real IAM role, credentials issued by the cloud's own STS.
  • Why it matters to a CTO: the IAM role is the cloud's native authorization boundary; binding to it means your access reviews run against real IAM, not a side table only AuthFI understands.
AssumeRole flow
  1. 1
    AuthenticateUser signs in to AuthFI (MFA where the mapping requires it).
  2. 2
    MapGroup membership resolves to the IAM role for the target account.
  3. 3
    ExchangeAuthFI presents an OIDC token; the cloud's STS validates trust and issues credentials.
  4. 4
    LandConsole SSO opens already assumed, or the CLI receives short-lived keys.
No per-account SAML app. No AKIA… key to rotate.

Role discoveryNew

Live role discovery — never type an ARN again.

Paste a read-only credential. AuthFI calls AWS / GCP / Azure on your behalf, lists every IAM role in the account, and turns the role-mapping form into a searchable typeahead. The typo class of misconfiguration — a fat-fingered ARN that silently grants the wrong access — goes away, because you bind to roles the cloud actually returned.

Step 1 — connect

Paste a least-privilege key

AWS access key with iam:ListRoles, GCP SA JSON with roles/iam.roleViewer, or Azure SP with Reader. AuthFI verifies the credential synchronously.

Step 2 — discover

Roles populate in seconds

Every IAM role from the account appears in the admin console, split into built-in vs custom, with attached policies summarised inline. Searchable, clickable.

Step 3 — bind

One-click group assignment

Click a discovered role, pick an AuthFI group, done. Members assume the role via console SSO or short-lived CLI credentials, audit-logged per request.

Credentials sealed with envelope encryption (KMS-backed in prod). Discovery refresh runs daily. When you're ready, swap to OIDC federation — no long-lived secrets at all.

Short-lived by default

Temporary credentials. Always. One audit trail across four clouds.

Every credential AuthFI hands out is an STS session that expires on its own — there is no long-lived secret to revoke, rotate, or lose. Step-up MFA is enforced per cloud-and-role combination, and every issuance is one row in a single audit trail: who assumed what, in which account, when, and from where.

No static keys

Every credential expires. 30 min to 12 hours, configurable per role. No long-lived secrets — expiry is the revocation.

MFA per mapping

Require MFA for production access. Skip for dev. Configurable per cloud + role combination, evaluated at credential-issue time.

Unified audit

Every cloud credential issuance logged. Who accessed what, when, from where. One audit trail across AWS, GCP, Azure and OCI.

Cloud access log
TimeUserCloudRoleMFA
10:30alice@acme.comAWSPowerUserYes
10:32alice@acme.comGCPEditorYes
10:45bob@acme.comAWSS3ReadOnlyNo
11:00charlie@acme.comAzureContributorYes
Trust
OIDC / RFC 8693 exchange
Credential
STS, 30 min – 12 h TTL
Standing keys
None
Audit
1 row per issuance

Private connectivityEnterprise

Private connectivity — no public exposure.

Reach AuthFI privately — over AWS PrivateLink, VPC peering, or the WireGuard mesh. Sensitive endpoints never touch the public internet. It's also how your cloud VMs reach the AuthFI Directory DC privately: no exposed controller, no VPN appliance.

AWS PrivateLink

Primary

The primary path. Reach AuthFI through a private VPC endpoint — traffic never leaves the AWS backbone and AuthFI is never exposed to the public internet.

VPC peering

Optional

Prefer to peer directly? Connect your VPC to AuthFI over a private peering link instead, with routes scoped to exactly the endpoints you need.

WireGuard mesh

Endpoints

For private endpoints and hybrid networks, the AuthFI WireGuard mesh extends the same encrypted, identity-bound fabric down to individual hosts.

No internet exposure

Default

Sensitive endpoints stay off the public internet entirely. This is how your cloud VMs reach the AuthFI Directory DC privately — no exposed controller, no VPN appliance.

Private by default, public never required. Your VPCs talk to AuthFI; the internet doesn't.

Get started

Ready to get started?

Free for 5,000 monthly active users. No credit card required.

Start free Read the docs