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
- 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!