Blog · Guides

What an authentication platform actually includes (and what a library does not)

A checklist for evaluating authentication platforms: protocols, user directory, MFA and passkeys, provisioning, authorization, multi-tenancy, admin tooling and deployment options.

Casdoor Team · November 1, 2026 · 3 min read

This guide is written by the team that builds Casdoor and describes the standards as published (listed under Sources), with notes on how Casdoor implements them as of November 1, 2026. Spotted a mistake? Tell us.

"Authentication platform" gets used for everything from a password hashing library to a full identity provider. The difference matters when you are choosing what to build on, because most of the hard work in authentication is not the login form — it is everything around it.

This article is a checklist. If a product is missing more than a couple of these items, it is not a platform; it is a component.

1. Protocols

An authentication platform must speak the protocols other systems already use:

  • OpenID Connect for modern web and mobile applications.
  • SAML 2.0 for enterprise customers, which is still the default language of procurement.
  • CAS if you have legacy or academic applications.
  • OAuth 2.0 for API access and machine-to-machine tokens.
  • LDAP if appliances or legacy systems need a directory endpoint.

A platform that only supports OIDC is fine for a consumer app and a problem for a B2B product with enterprise customers.

2. A real user directory

Not just a users table: a directory with organizations, groups, roles, custom attributes and search. Enterprise customers will ask for:

  • Attribute mapping from their identity provider.
  • Group and role synchronization.
  • Multiple organizations under one tenant.
  • An admin API for everything the console can do.

3. Strong authentication

Password login alone is no longer defensible. The baseline:

  • MFA with TOTP, email and SMS, plus WebAuthn/passkeys as the phishing-resistant option.
  • Password policies and breach checks.
  • Session management: timeouts, device lists, forced logout.
  • Account recovery that does not quietly bypass all of the above.

NIST SP 800-63B is the reference for what "strong" means; it also restricts SMS as a default authenticator.

4. Provisioning

Users have to arrive and leave. The platform should support:

  • Just-in-time provisioning from SAML or OIDC assertions.
  • SCIM 2.0 for create, update and deprovision from Okta, Entra ID and similar.
  • Bulk import for migrations.

Without SCIM, deprovisioning is manual, which is the first thing a security review will flag.

5. Authorization

Authentication answers who; authorization answers what. A platform should have roles, permissions and a policy model that applications can query — ideally with a standard model such as RBAC, with room for attribute-based rules.

6. Multi-tenancy

If you sell to businesses, each customer is a tenant with its own users, branding, identity providers and possibly its own domain. The platform needs a first-class tenant model, not a naming convention.

7. Admin tooling and audit

  • An admin console for day-to-day operations.
  • An API for automation.
  • Audit logs for sign-ins, admin changes and provisioning events, with retention you can defend.
  • Exportable logs for SIEM integration.

8. Deployment options

  • Self-hosted for data residency, private networks and air-gapped environments.
  • Managed for teams that do not want to run it.
  • A migration path between them.

A platform that only offers one of these forces a decision many companies are not ready to make.

Platform vs library vs build-your-own

Approach You get You own
Library (passport, auth.js, Spring Security) Login mechanics in your language Everything else: directory, MFA, SSO, provisioning, operations
Identity provider (self-hosted or managed) The full list above Integration and configuration
Build your own Exactly your requirements All of it, forever

Libraries are the right choice for a prototype or a single-tenant app with simple needs. They become expensive the moment an enterprise customer asks for SAML and SCIM.

A quick evaluation script

  1. Ask for the protocol list and the license.
  2. Ask how multi-tenancy works, with a concrete schema or API example.
  3. Ask how a customer's SAML connection is configured per tenant.
  4. Ask what SCIM covers (users, groups, deprovision).
  5. Ask for audit log retention and export.
  6. Run a proof of concept with one real application and one real upstream IdP.

If a vendor cannot answer 2 through 5 with specifics, the demo is doing the talking.

For the open-source options that pass this checklist, see open-source identity servers.

Casdoor covers the checklist above — OIDC, SAML 2.0, CAS, SCIM, LDAP, MFA and passkeys, organizations and roles, admin API — and is open source and self-hostable, with a hosted option from $9 per month.