Choosing an identity provider is one of the few software decisions that touches every employee, every customer and every application. It is also hard to reverse: once passwords, passkeys and a hundred application integrations live in one system, moving is a project measured in quarters. A demo shows the sign-in page. This checklist is for everything behind it.

How to use this checklist

Do three things before you speak to a vendor.

  1. Write down your populations. Employees, contractors, customers, partner organisations, service accounts, AI agents. Each has different needs, as described in workforce vs customer identity.
  2. List your applications by protocol. Which speak SAML, which speak OpenID Connect, which speak neither.
  3. Mark each item below as required, wanted or irrelevant for your situation.

Then ask each vendor the same questions and ask to see the answer working, not described. For anything on a roadmap, ask what state it is in today.

Protocols and sign-in methods

Protocols

An identity provider is only as useful as the standards it implements, because standards are what let you connect things the vendor has never heard of.

  • OpenID Connect and OAuth 2.0. Authorisation code flow with PKCE, client credentials for machines, refresh tokens, a discovery document and a published JWKS.
  • SAML 2.0, in both directions. As an identity provider for applications you bought, and as a service provider so people can sign in from an upstream directory.
  • SCIM 2.0, in both directions. Inbound from your HR system or directory, and outbound to the applications people use.
  • LDAP or Kerberos, if you still run software or machines that expect a directory.

Ask whether tokens can be verified by any standard library. If the answer involves the vendor's SDK, you are buying lock-in.

Sign-in methods

  • Passkeys (WebAuthn), as a first factor and as a second.
  • Authenticator app codes (TOTP), with backup codes.
  • Passwords with a sensible policy and lockout after repeated failures.
  • Email codes or links, and social sign-in if you serve customers.
  • A second factor on every plan, not only the expensive one.
  • Step-up for sensitive actions.

Ask how account recovery works for each method. A phishing-resistant sign-in with a weak recovery path is a weak sign-in.

Lifecycle, administration and audit

Lifecycle

  • Are accounts created automatically on first sign-in, ahead of time over SCIM, or both?
  • When someone is removed upstream, how quickly does their access end, and does that include active sessions?
  • Can access be granted by group, so that a change of team changes access everywhere?
  • Can a grant carry an end date and lapse by itself?
  • For customer identity: organisations with their own members and admins, invitations, and a customer's own single sign-on.

Administration

  • Granular admin roles. Can you give someone the ability to reset passwords without the ability to change signing keys?
  • Custom roles, and a clear view of who holds each.
  • An API for everything the console does, so configuration can live in code.

Audit

  • Is there one record for sign-ins, admin changes and access decisions, or several?
  • Are refusals recorded, with a reason, or only successes?
  • Is the record tamper-evident, and can you verify that yourself?
  • Can it be exported continuously to your own log tool, in a documented format, at no extra charge?
  • Can individual sessions be listed and revoked?
  • Are revocation events pushed to your applications, so a revoked session stops working before its token expires?

Data residency and key custody

Residency

  • Can you choose the region when a tenant is created?
  • Which data stays there? Ask separately about profiles, credentials, sessions, the audit record and keys.
  • What does the vendor's global control plane hold about your users?
  • Can the product run in your own cloud account or data centre, and is that the same product or a different one?

Key custody

  • Does each tenant have its own signing keys, or do tenants share one?
  • Where are private keys stored, and can any person at the vendor read one?
  • Can you rotate a signing key without signing users out? What is the overlap window?
  • Can you bring your own key, or hold keys in a hardware security module?

AI agents and machines

Add this section even if your first agent is months away.

  • Can an agent have its own identity, with its own key, distinct from the person it acts for?
  • Can an agent's permissions carry limits, such as a maximum amount or an allowed set of values?
  • When an agent acts for a person, is that delegation explicit, and is the agent limited to what the person can do?
  • Can a sensitive action wait for a named person's approval, and is silence treated as refusal?
  • Are tool calls recorded on the same audit record as human actions?

The concepts are introduced in what is AI agent identity.

Pricing and the exit plan

Pricing

  • Is the price per user, per active user, per connection or flat?
  • Which features sit behind a higher tier? Single sign-on, SCIM, a second factor and audit export are common examples.

The exit plan

  • Can you export every user, with profile attributes, group memberships and identifiers?
  • Can you export password hashes, and in which algorithm? Without them, every user resets their password on the day you leave.
  • What happens to passkeys? A passkey is bound to the domain that registered it. If sign-in runs on your own domain, passkeys can survive a change of vendor. If it runs on the vendor's domain, they cannot.
  • Can you keep the audit record after the contract ends?

How AuthFI answers these

We build an identity provider, so here is how AuthFI stands against its own checklist, including where the answer is "not yet".

  • Protocols. OAuth and OpenID Connect, SAML 2.0, SCIM 2.0 in and out. A directory service for Windows and LDAP is in pilot. Tokens are verified by any standard OAuth library, with public keys at a standard address.
  • Sign-in. Passkeys, authenticator codes and passwords with lockout, and a second step on every plan.
  • Lifecycle. Access by group across applications, cloud roles and servers, and organisations with a customer's own single sign-on.
  • Audit. One chained record for people and agents, with refusals, session revoke, pushed revocation events and export to your log tools. Compliance reports are in development.
  • Residency. A project lives in one region for life: US East, Mumbai, or your own cloud or data centre on the Enterprise plan. See keeping identity data in your region.
  • Keys. Signing keys per project, rotation with a 24-hour overlap, and a separate disable. Bring your own key and hardware security module support are in development.
  • Agents. An identity per agent with its own key, permissions with limits, approval by a named person and a gateway for tools.
  • Pricing. Plans are not priced per user. Current plans are on the pricing page.

Each part states whether it is available, in pilot or in development on the platform page.

Key takeaways

  • Decide what is required for your populations and applications before you see a demo.
  • Favour open standards in both directions. They are what keep the exit possible.
  • Ask about residency and key custody item by item, not as a single yes or no.
  • Add agents and machine credentials to the checklist now.
  • Settle the exit plan, especially password hashes and passkey domains, before you sign.