🧪 Beta — Available today; the interface contract may still change.

Connect Authing

This page covers how to configure Authing as GenAuth's Human IAM provider. The integration maps one-to-one onto the three capability surfaces in F1 Integration principles: directory reads (who the user is), federated login (confirming consent with an enterprise account), and permission evaluation (what the user can do).

By the end of this guide you will:

• Understand how the Authing provider integrates — what OIDC federated login solves, and what directory and permission reads solve
• Configure the tenant and access credentials, then verify that user directory binding takes effect on delegation issuance
• Know what to watch for under a self-hosted same-domain sidecar deployment

Integration at a glance

Capability surface	Question it answers	Status
User directory binding	Does the delegating user actually exist in the directory	🧪 Beta (in effect on every delegation issuance)
OIDC federated login	Which account does the user sign in with at consent time	🚧 Roadmap
Directory / permission reads	The person's real permissions — the attenuation floor of the three-way intersection	🚧 Roadmap

Prerequisites

• On the GenAuth side: a tenant and access credentials (AK/SK). Creating and rotating tenants and credentials goes through the /api/v3/eak/tenants family of endpoints; see API Reference for the full contract.
• On the Authing side: a user pool (user directory) that serves as the authoritative source for users.
• Differences by deployment model: in the SaaS model the delegation user directory is hosted on the tenant side, so directory binding works out of the box. In the self-hosted same-domain sidecar model the directory authority is the Authing instance inside your domain — the rest of this page follows the self-hosted sidecar as its main line. For the differences, see Deployment models.

Bind the user directory: delegation starts by confirming the person exists

Directory binding is the Authing provider surface that is live today. Once you bind a user directory during tenant initialization, every user in every delegation request resolves against that directory as the authority. Before issuance, GenAuth verifies that the delegating user really exists in the directory; a user who does not exist gets no Delegate Token at all.

Your code does nothing extra: start the delegation as usual, and the directory check happens inside GenAuth.

import { Qoni, AnimaScopes } from "@eazo/anima";

const anima = new Qoni({
  host: "https://api.eak.eazo.ai",
  accessKey: process.env.ANIMA_ACCESS_KEY!,
  secretKey: process.env.ANIMA_SECRET_KEY!,
});

// Start an interactive delegation for a real user in the directory
const { data } = await anima.delegateToken({
  mode: "interactive",
  agent: "report-agent",
  scopes: [AnimaScopes.WEB_SEARCH_RUN, AnimaScopes.WEB_SEARCH_READ],
  redirectUri: "https://yourapp.example.com/callback",
  state: "opaque-state",
  user: { id: "usr_demo_0001" }, // use the user identifier from your directory
});
// data.authorizationUrl — hand this to the user to complete consent

For the whole delegation loop (callback, getting the token, token exchange), see Your first delegation in 30 minutes.

Configure OIDC federated login

🚧 Roadmap — The capability described here is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.

Federated login solves the "front door" of the consent screen: when the user opens it, they are redirected to Authing to authenticate with their enterprise account, and the identity assertion returns to GenAuth — so the person at the consent screen and the person in the directory are the same person. This is hop ⑧ of the full journey:

The integration uses the standard OIDC authorization code flow. When it ships, you will prepare an OIDC application on the Authing side and hand GenAuth the following conceptual parameters (the exact configuration entry point is subject to the final release):

Conceptual parameter	What it does
Issuer	Lets GenAuth discover Authing's OIDC endpoints
Application ID / application secret	GenAuth's identity as an OIDC client
Redirect URI	Where the identity assertion returns to GenAuth after authentication
Requested scope (openid profile, etc.)	Decides which basic claims the identity assertion carries

Until federated login ships, sign-in on the consent screen is completed against the user directory session inside GenAuth's own domain.

Configure directory / permission reads

🚧 Roadmap — The capability described here is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.

Permission reads answer the "person's real permissions" set in the three-way intersection (for the mechanism, see F1 layer 2 and Delegate Token and attenuation). How it integrates: through the provider, GenAuth evaluates the user's permission assertions in the Authing directory (roles, groups, permission points) read-only, and the assertion is used only to narrow the delegation, never written back. The three hard boundaries match F1: read-only, real-time, intersect without widening.

Self-hosted same-domain sidecar: what to watch for

In the self-hosted model, GenAuth is deployed as a microservice component alongside Authing in the same Kubernetes namespace (for the full topology and boundary matrix, see Deployment models). Keep your eye on four things:

• Traffic never leaves the domain — federated redirects and directory/permission reads all stay on in-domain traffic; user credentials and permission data never cross your boundary.
• Same-domain callbacks — keep the consent screen and the Authing login page on the same domain or mutually trusted domains, so cross-domain redirects do not get blocked by enterprise browser policy.
• Credential boundary — all GenAuth holds is a read-only credential aimed at the provider. Service-to-service authentication (mTLS, secret management) follows the service-to-service authentication matrix in G2.
• Air-gapped works — in an offline deployment, provider integration also completes entirely inside your domain, with no external dependency.

Verify

Once the delegation loop completes, use the released SDK's introspection call to check who the token belongs to:

const info = await anima.genauth.introspectDelegationToken({ token });
// Check: sub (the person, from your directory), agent_id, scope, grant_id, audit_id

sub should point at the user in your directory who granted the authorization — that is the direct evidence that directory binding is in effect. For the full claim table, see Token and claim reference.

FAQ

Do I have to migrate my users into GenAuth? No. Directory authority stays in your Authing user pool. GenAuth only reads and verifies; it never takes over and never writes back. This is what F1 means by "connecting is not migrating".

Delegation issuance says user validation failed. Why? First check that user.id comes from the directory you bound — the most common cause is starting a delegation with a user identifier from a different system. GenAuth rejects users that do not exist in the directory before issuance.

Can I configure federated login today? Not yet; that section is Roadmap. For now, sign-in on the consent screen is completed against the user directory session inside GenAuth's own domain. After release, redirecting to Authing for enterprise-account authentication will be supported.

I do not use Authing. What then? See F3 for how Azure AD (Entra ID), Okta, and standard OIDC integrate — the provider abstraction guarantees they all speak the same integration language.

Next steps

• Get started: Your first delegation in 30 minutes — run the whole delegation loop once
• Architecture: Deployment models — data boundaries and the call authentication matrix for the self-hosted same-domain sidecar
• Reference: API Reference — the full contract for tenant, credential, and delegation endpoints