The reason for deploying a Single Sign-On solution is vital for your decision to opt for it. Each and every company should make simplicity for all users the objective with Identity & Access Management and Single Sign-On, for shop or service end users, as well as development teams, internal audit and risk officers, etc. The idea is to primarily deploy SSO so each user type can carry out their user tasks efficiently and easily. The meaning of this ‘simplicity’ for all of the different users is the basis of your SSO solution.

It is logical to set up Single Sign-On as a separate service at a central location to correctly design this simplicity. This means that one single service deals with and directs authentication, user roles and user rights. Identity information is saved in this separate service, or connected ‘directory’, and is separate from the rest of the services and components. This has various advantages:

• Development teams do not have to worry about user data and corresponding privacy issues, because this is dealt with in a separate SSO service. This ensures increased focus and a shorter time-to-market in software development.

• User roles, authentication and access are much more easily controlled if this is done at one single location. This makes onboarding and, often even more complex, offboarding of all different users much simpler and faster.

• If your ambition is to grow substantially, the flexible architecture with modern connectors (APIs) and technology (such as Oauth, SAML and OpenID Connect) helps accelerate your growth.

How you decide to deal with this selection process usually also depends on who is asking: the business, or IT. Based on our experiences with SSO implementations, we have drawn up a checklist to provide direction to this approach. Following are the topics to bear in mind:

• Authentication process: To what extent does your process deviate from the standard? What type of services are found in the landscape? Is a Windows login required or an external ID via Facebook or Google, for example?

• Authentication devices: Which authentication methods are required? This depends on the services and target groups you service, so be sure to consider the device type to be supported, as well as the login type. Will you be working with two-factor (2FA) and multi-factor authentication (MFA), and what do you require from the device?

• Repeated use from the same devices: Are many users involved in a BYOD (Bring Your Own Device) landscape on which logins can be ‘saved’, or are users required to re-identify themselves time after time on shared hardware?

• Digital experience: What are your requirements in the area of the user experience? Consider the ease with which you run through flows, the number of steps in onboarding, offboarding and recurring login, the speed required for systems to respond and the (various) ways for someone to be able to log in.

• Cloud, on-premise or hybrid: If the landscape in the cloud is hosted and direct cloud services such as Azure Logic Apps or certain applications from the AWS Marketplace are used, you might also consider specific cloud solutions for SSO, such as Azure SSO or AWS Cognito.

• Standard versus customisation: To what extent is the development of custom API connectors required or desirable, or might standard connectors of an IAM or SSO platform be sufficient?

• Control over costs: How many users do you expect? What are your expectations in the growth of the number of users and how frequently will/do they log in? This affects the payment model of the solution you choose. If you have a substantial number of low value users, you may wish to pay for actual use, such as a number of logins or API calls, or a bundle of these.