IdP for AI agents

Why purpose‑built for agents

• Agent→user binding; authorize on sub, record act.sub, keep client in azp
• Batched capability asks (RAR) with optional PAR/JARM
• Consent at issuance; obligations handled before tokens mint
• Proof‑of‑possession (DPoP) for agent runtimes
• Resource‑targeted audiences (RFC 8707) → fewer 401s

Using External IdPs with EmpowerNow

Federate to your corporate IdP (Microsoft Entra ID, Okta, Auth0) for login, then complete OAuth/OIDC locally so you retain control of token issuance, claims, and policy.

Use cases

• Standardize tokens across apps while using the corporate IdP for login
• Migrate or multi‑IdP with a unified claims contract
• Step‑up and consent based on risk/policy—even after upstream auth
• Fine‑grained API authorization with consistent scopes/claims
• Developer tokens and introspection alongside JWTs

Federate but orchestrate

• Redirect to upstream for login; return and orchestrate locally
• Apply obligations (step‑up MFA, consent, risk) and bind sessions
• Outcome parity with “authentication actions” via policy‑driven rules

Collaborative adaptive authentication

• Normalize upstream attributes to canonical claims; decide locally
• Emit identity events for analytics and adaptive posture

Standards we implement for agents

Auth Code + PKCE, Refresh, Client Credentials, Introspection. Optional: PAR, JARM‑style JWT responses, CIBA, DPoP, RFC 8693 Token Exchange, JWE/JWS. Discovery advertises supported grants/algorithms; middleware can enforce FAPI‑style rigor.

Minimal RAR object

{
  "authorization_details": [
    {
      "type": "tool",
      "actions": ["invoke"],
      "resource": "billing.export",
      "locations": ["https://api.example.com"],
      "dat": { "purpose": "monthly_report" }
    }
  ]
}

Claims & scopes

• Canonical identity‑first claims with provenance (`orig_iss`, `orig_sub`)
• Composable claims merged from upstream + internal sources
• Per‑client customization without leaking provider specifics
• Introspection parity for local/external tokens

Architecture at a glance

1. Login at corporate IdP → return to EmpowerNow
2. Orchestrate obligations and assurances
3. Issue policy‑controlled tokens / introspection with canonical claims
4. Enforce with PDP/services; analytics feed adaptive auth

Getting started

1. Configure upstream provider (discovery/JWKS, redirect URIs)
2. Enable federation and mapping
3. Define canonical claims and any internal sources
4. Enable advanced features as required; verify via discovery
5. Test end‑to‑end (login, step‑up, issuance, introspection)