How to choose an Identity Provider (IdP)

19 September 2023

As independent security consultants we have had the opportunity and privilege to help our customers selecting and implementing a plethora of different solutions.In this article we aim to share with you some of the key factors to consider when selecting the right IdP solution for you, a central part of your architecture and IAM solution.

IdP, AS, STS, etc. the list goes on. While there may be slight variations in the definitions of the terms, we have chosen “IdP” as the catch-all term for the service which you authenticate towards and receive tokens from.

In our experience the following questions need to be considered to make a successful selection:

The answers to these questions will depend heavily on your context. The basic question are however the same. The goal of this article is to help you formulate additional questions to answer depending on your context. Our experience is that this list is a good starting point for a successful implementation.

Identity modeling

Identity modeling and how to balance central identity with local permissions is covered in-depth in Defence in depth: Part 1 of 7

Carefully modeling the identifies in the system helps us answer the first questions:

This also gives us a “map” of our system, the model of our identity and through that what information is needed from the authentication response to enable the required level of access control granularity for each service.

Tobias Ahnoff, Omegapoint

We really want to emphasize the importance of performing this analysis. It’s impossible to secure that which you do not understand. For large systems it is often hard to keep the system overview updated and we are often able to identify weaknesses through this initial analysis.

Authentication and administration of users

From an early stage you need to identify the requirements in place for authentication. Some organizations are governed by laws, EU directives or industry standards. For example support for multi factor authentication (MFA) might be required. Authentication is also an part of an application’s user experience and can be a crucial part of the user journey for an e-commerce site. Our experience tells us that it’s important to understand your requirement regarding authentication at an early stage since there is large differences between IdP solutions.

A common use case is that your IdP does not perform the actual authentication of users but instead relies on other IdPs to perform it through social login, Azure AD or some kind of electronic ID such as BankID. This type of integration is usually built on OIDC or SAML but it’s quite common for IdP products to not support electronic ID cards out of the box and may require custom integration work.

With a growing number of clients it’s important that your IdP offers an easy to use UI or API to manage them. For large-scale deployments this may be handled through specification add-ons for dynamic client registration such as https://tools.ietf.org/html/rfc7591

Another important question to ask yourself is whether you need to support local users. In that case you need to find an IdP that enables you to manage and administrate not only your client but also the local user accounts.

How authentication and password should be handled is covered in-depth in OWASP ASVS, section V21 and OWASP Cheat Sheets2. Remember that these requirements bring increased development and implementation costs. It might be more economic and better to integrate against a system that’s already in place, such as Azure AD.

Kasper Karlsson, Omegapoint

During penetration tests we come across vulnerabilities regarding password management. By looking closely at how local passwords are created, stored and reset you often get a fairly good understanding of the application’s general security posture.

Read more about penetration tests in our article Offensive application security.

By considering the above we should be able to answer the following questions:

Permission management

Managing permissions is closely tied to the administration of users. For a system architecture that is maintainable over time it’s important to keep the two parts, authentication and authorization, apart. How to correctly balance this is covered more in the articles on Identity Modeling and Claims-based Access Control.

In this article we want to emphasize the importance of not introducing domain-specific permissions in your IdP solution. A good rule of thumb is that you should be able to change IdP, protocol and token format without affecting the access control in the services using the IdP solution.

How you manage permissions is important. Weaknesses in that can lead to critical vulnerabilities and it’s crucial to find a solution that fits your organization. The solution might be that each service or sub-domain independently manages its own permissions, or all services using a centralized permission service to query roles and rights for each user. Some information may be so central to your identity model that you make it part of the authentication response, for example one or a few AD group memberships. This might be sufficient for some organizations with a less complex access control model and no additional permission management is needed.

In large systems with a complex access control model there’s usually a need for one (or more) domain specific applications for managing permissions for all services. Such an application should produce a complete and easy to interpret audit log over how permissions have changed over time, as well as a well-defined user interface showing any changes currently under way. Implementing such a system is easier said than done, do not underestimate the development effort and cost of building it yourself.

Tobias Ahnoff, Omegapoint

Don’t underestimate the cost of implementing this on your own in a secure manner. There is a clear need for balancing requirements from the organization regarding administration, operations and maintenance.

Martin Altenstedt, Omegapoint

Another important aspect of permission management is system performance and how fast you can revoke permissions. There’s a balance between number of queries and caching, but also the interface offered to administrators, spanning all services.

Through this we have answered: How are access rights and permissions administrated?

Authorization flows, clients and frameworks

How users can delegate authorization to a client and what flow to use depending on the client is described in the article Clients and Sessions. Note that different protocols can be used and you ned to pick a protocol that matches your requirements based on laws and industry standards while also supporting your integrations.

As an example there are many IdP products on the market supporting OAuth 23 and OIDC4, but only a small subset of the support the requirements of the financial sector like FAPI 5. It’s important to select an IdP that offers you the correct support depending on the requirements on your organization and industry.

Tobias Ahnoff, Omegapoint

FAPI is an excellent resource for anyone, not just for those in the financial and banking sector, regarding the necessary steps to increase the default security level of OAuth2/OIDC.

Another example of requirements that are important to capture at an early stage is if you need to support multiple authorization protocols. For example during a migration period from SAML to OIDC.

Martin Altenstedt, Omegapoint

Those of us that have been in the business a few years have seen the move from WS-* and SAML to OAuth 2 and OIDC, with additions such as OAuth 2.1 and FAPI. Even if the current landscape is somewhat stable with wide support there is talk about “OAuth 3” 6. This shows how important it is to avoid lock-in on the protocol level. New requirements may force you to more to new protocols or even IdP solution.

The big strength of these flows is in the authentication of user and client, and that the user always authenticate towards the IdP, not the client. In other words, the client can never access the user’s secret. This is very important when talking about so called third-party clients, but there is a weakness in the complexity redirects bring with them.

If you have only a “first-party” client, OAuth 2 and OIDC might not be the right solution for you?

It’s however still important to understand that custom solutions for authentication, with where the user authenticates towards the client, makes it difficult to support other types of authentication, such as strong authentication through MFA. Single Sign On (SSO) is also difficult to support and manage in this type of solution.

OAuth2 with the flow Resource Owner Password Credentials (ROPC) might seem attractive at first glance since it enables using standard protocols and solutions with an IdP to gain support for example SSO. However, ROPC is not part of OAuth 2.1 and the current best practices because of the issues with local authentication in the client and that strong user authentication through MFA is not supported.

Regardless of the chosen solution it’s important to make sure there are frameworks available for the protocol to be used. This helps those building clients and services to create secure implementations. Implementing the solution should be more a matter of configuration rather than custom implementation and code.

Martin Altenstedt, Omegapoint

OAuth 2, OIDC and JWT tokens are easy to handle on most platforms today. The same can not be said for SAML and WS-Fed. Even if there are features in a protocol that are attractive to use it might not be the right solution due to the platform support.

In this section we have provided additional insights to answer the questions:

Sessions and custom UI

A common requirement for your IdP will be to support Single Sign On (SSO) for web applications. Most product implement this using a cookie to track the session between a user and the IdP. This is however generally not enough to provide a seamless user experience. Common additional requirements for your IdP apart from SSO are, “single logout” and sliding sessions. Support for SSO sessions vary among IdP products as it falls outside of standards like OIDC.

Today there’s broad support for the core specification of OIDC among IdP product but the support for additional specifications such as sessions and back-channel-logout varies. Is this supported by your chosen IdP solution?

The local sessions towards each client is owned by the clients and must be secure regardless if SSO is used or not. There is however need of co-operation to enable a good user experience. You can read more about sessions and tokens in our article on Clients and Sessions.

It’s important to verify that your chosen IdP solution supports manipulating parameters for tokens and SSO sessions depending on your requirements on single or all clients.

Martin Altenstedt, Omegapoint

The availability of secure and easy-to-use libraries for your clients is important so that tokens and sessions are handled coherently throughout the system.

Tobias Ahnoff, Omegapoint

Worth mentioning is that you by default get SSO between all clients that trust the same IdP. If this is not the desired behavior there’s likely a need for extra configuration of the IdP that’s unique to you and may be a requirement difficult to meet out of the box.

Apart from securely handling sessions and properly implementing access control, another important aspect of the chosen IdP is the user experience. The user interface shown at the time of log in might be the first this presented to a user and it’s important that it makes the user feel safe.

When selecting an IdP make sure that it’s possible to:

Part of OIDC are for example the parameters ui_locales and login_hit to control the display language and pre-populate username at the time of authentication. Is this supported by your IdP?

Before we move on to the next topic there are two more requirements related to sessions that often need to be addressed:

Martin Altenstedt, Omegapoint

This type of requirements are important to catch early on as such features might not be supported by many off-the-shelf products.

With this information we have answered the following:

Operations, maintenance and development

Your IdP is a critical part of your system and plays a huge part in how stable and secure your system will be in production. It is increasingly so for systems with strict security requirements including reference tokens and short-lived tokens. The IdP becomes a single point of failure and a couple of minutes of downtime may affect the whole system, not just a given service.

Martin Altenstedt, Omegapoint

Our experience is that one deciding factor when selecting an IdP is often; to self-host or not. Can your organization handle 24/7 operations? Availability is also security!

When discussing these topics there’s also the matter of licensing models, for example per user or token request, etc. What we want to highlight here is the importance of having the complete set of requirements when choosing an IdP. It might not be possible to customize some products according to your requirements, or the cost might increase significantly when you leave the paved path of default functionality.

An IdP should, just as all other services and clients, provide the logging necessary for traceability and intrusion detection. Are you able to detect attacks and act by for example disabling an account fast enough?

Kasper Karlsson, Omegapoint

When we perform a penetration test we ought to trigger your intrusion detection system. If we don’t, chances are that a real attacker will fly under the radar.

As with any kind of service it’s important that you IdP supports rotating any secrets such as the keys used for signing tokens and client credentials used for authentication of clients.

Rotating secrets for token signing is something that your IdP and frameworks/libraries for services and clients must handle. Additional planning might still be needed by the organization to make sure keys are rotated at the right time.

To rotate client credentials is an important security aspect that is often overlooked. What API of your IdP should you use to perform recurring rotation of client secrets? A good rule is that each client should be configured with at least two active credentials (of the same kind) so that one can be rotated without any downtime. How you distribute client credentials is also very important, what kind of support does you IdP solution offer?

Looking forward it’s also important that your chosen IdP solution is kept updated and supports any protocols that need to be supported by your system. It’s impossible to predict the future, but by building your system to not be protocol dependent and avoid domain specific access control decisions in your IdP you are well prepared for most things.

In this final section we have covered:

Summary

Choosing an IdP is not done in a heartbeat and its important to perform the analysis described in this article right from the beginning. The questions are easy to ask, but the reality of most businesses and organizations is complex and the answers may be difficult to translate to a concrete implementation.

An incorrect set of requirements may lead to a more expensive and complex solution, or a too simple one. It should be clear to everyone reading this that there’s a strong connection between architecture and security, that security is best built in multiple layers and not something that can be added in front of you applications. We at Omegapoint would be happy to help you on this journey!

Related content

Defence in Depth

Footnotes

  1. https://owasp.org/www-project-application-security-verification-standard/ ↩

  2. https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

    https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

    https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

    https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html ↩

  3. https://oauth.net/2/ ↩

  4. https://openid.net/connect/ ↩

  5. https://openid.net/wg/fapi/ ↩

  6. https://oauth.net/3/ ↩