Choosing the “best” IDP — points to consider

Just to be clear, an IDP is an Identity Provider.

I see questions like this all the time:

“Help me pick between Okta, Auth0 and Azure AD for my project.”

The thing is that there is no such thing as a general “best” IDP. There is only an IDP that is the closest fit to your requirements. So the above question is impossible to answer because you have no idea what boxes need to be ticked.

e.g. your requirement is to have everything on-premises. Boom! You’ve just blown all the cloud IDP out of the frame.

I did this post a while back that compared the IDP that I use on a regular basis but it is slightly out of date.

So what areas do you need to look at in order to find the best fit for you? Basically, you need to figure out your requirements.

The following is a list of the possible requirements you may want to take into account.

Essentially, does the IDP you want need to have support for:

Protocols

WS-Federation

There are two profiles:

• Passive — browser based
• Active — API typically WCF

OpenID Connect / OAuth 2

There are four flows:

• Application code grant flow
• Implicit flow
• Client credentials flow
• Resource owner password flow
• Support for the Device Authorization Grant (formerly known as the Device Flow)
• Support for PKCE
• Support for protecting REST API
• Support for impersonation / on-behalf flows

SAML

• SAML 1.1 or SAML 2.0
• IDP or SP Initiated or both
• Artifact resolution

Federation

• SP only i.e. your IDP will use another IDP to authenticate
• R-STS i.e. your IDP can support federation both upstream and downstream
• IDP i.e. users can authenticate here
• Built-in support for common SaaS integrations e.g. SalesForce, Workday, ServiceNow
• Social support e.g. Twitter, Facebook, Google
• Is metadata available

MFA (Multi-factor Authentication)

Also known as 2FA (Two-factor authentication).

• Via SMS
• Via authenticator application using codes
• Via authenticator application using push notification
• Via phone call
• Via email
• Passwordless
• WebAuthn / FIDO 2
• Certificates
• Step-up authentication

Client-side libraries

• Available for a wide range of languages
• Covers all protocols
• Standards based e.g OWIN

Documentation

• Good documentation with lots of sample code
• How-to documentation e.g. how to integrate with Ping Identity

Cost

• Free
• Free — base only / pay for extra features
• Ability to upgrade to paid version
• Cost per user or per integration or both

Support

• Paid — turnaround in hours
• Email — turnaround in days
• Forum — turnaround in weeks
• Local support in your region / time zone

Claims

• Claims rules
• Ability to add / transform claims

Configuration

• Via portal
• Via code (API)

Availability of API

• API support for admin. tasks e.g. creating application
• API support for authentication / authorisation endpoints. Endpoint support allows the use of your own login screen

Customisation

• Can customise login screen
• Ability to add workflows
• Ability to hook into workflows programmatically
• Uses open source so functionality can be customised

General

• Number of users
• Target audience corporate or customer or both
• Allow separate repositories for corporate and customer users
• SSO

Email

• Built in email support or have to use third-party e.g. SendGrid

Conditional access

• Conditional access e.g via groups, IP address, region, BYOD release levels e.g. latest level of device software

Reporting

• Logins / logouts
• Who is using what e.g how many people are using MFA
• Suspicious activity
• Auditing facilities

Passwords

• Don’t allow common passwords
• Password policies

Artificial Intelligence / Machine Learning

• Continuous assessment e.g. logins from two countries
• Detection and alerting e.g. emails and reports
• Remediation and mitigation e.g. proactively disable users

On-premises

• Can run on-premises
• For cloud, access to on-premises resources (e.g. SQL DB, LDAP, AD) via an on-premises agent
• For cloud, ability to write back to on-premises e.g. password change
• Synching users up to cloud and vice versa

Migration

• Support for migration of existing collateral
• Scripts available for migration from standard repositories

Repository

• Requires own, proprietary identity repository or can use standard ones e.g ASP.NET Identity, SQL DB
• If cloud, where is the data stored — data sovereignty
• How many data centres

Provisioning

• Support for user provisioning in Portal
• Support for group provisioning in Portal
• User provisioning via API
• Group provisioning via API
• SCIM support
• User provisioning inbound, outbound or both
• Trickle or JIT user provisioning
• Support for BYOD devices e.g. on-boarding, certificates
• Batch facilities

Self-service

• Self Service Password Reset (SSPR)
• Reset / forgotten password
• User can update profile
• User can self-manage without having having to contact help desk

Policies

• Configurable password policies
• Configurable account expiration

Tokens

• Token timeout configuration
• Token signing
• Token encryption
• Supported types e.g. SAML, JWT

Integration

• Deep integration with Office 365 in particular, SharePoint and Exchange Online

Environment

• Runs on Linux
• Runs on Windows
• Runs in a container

Admin

• Hierarchy of admin. rights to get “just enough privileges”
• Delegated admin.

Hopefully, with the aid of the above list, the question:

“Help me pick between Okta, Auth0 and Azure AD for my project.”

will become:

“Help me pick between Okta, Auth0 and Azure AD for my project. Hybrid is OK. 10,000 users max. OpenID Connect support with PKCE. Users currently in LDAP. Need authentication with Google, Twitter, Facebook. Need integration with ServiceNow”.

At least that gives me something to go on when I answer your question.

And please use a recognized IDP — do not try and roll your own! That way there be dragons 😃

P.S. If there are any requirements that I missed, please note in the comments and I’ll update the article.

All good!