I imagine you’re already cringing based on the title of the blog, but give it a chance in terms of what I am proposing and have been building with my customers.
I talk to a lot of CISO / Senior leaders and I hear consistently a few topics and struggles people are having.
- How do we reduce overhead / operational cost of running authentication infrastructure (e.g. performance, support, etc.)?
- How do we improve the experience of authenticating users to our applications while still maintaining security?
In talking, the primary question I ask people to help set this stage is “What is the #1risk of authenticating users to your applications”. Where I am taking people with this question is to focus on how you authenticate your users, primarily with passwords. The hardest, and riskiest, part of building and maintaining IAM is going to be the password assigned to users. Whether it is password policies, self-service, etc., the password is always going to be the target of attackers. So, the goal has to be efficiently remove passwords from the equation.
So, how do we do that. There are a ton of vendors in the space that have passwordless capabilities and will integrate with most IAM infrastrucure, but there is a cost and complexity associated with implementing these on top of existing infrastructure. If you have the budget and resources, go this route. But, if you don’t (which a lot of us don’t and are struggling with resource constraints), then we need to look at providers to authenticate users.
This is where I usually lose people and start raising some eyebrows. One of the suggestions I give to a lot of my customers is to look at the social provider integrations (e.g. Google, Facebook, LinkedIn, etc.). I always get the response of:
- “You can’t trust Facebook / Google / <insert anyone>, it’s the wild west”
- “I can’t verify the security practices / validity of the users, thus can’t trust the authentication”
[insert slammed door at this point]
But, in the responses, lies the solution. People look at social integrations as ‘Authentication’. I agree with every comment I usually receive, and the security side of me screams this is craziness. The security side of me also recognizes the struggle and challenges of passwords and knows we need a better solution. So, if we shift the focus and terminology of the exchange with the social providers from ‘Authentication’ to ‘Assertion of Identity’ then we can start breaking this down a bit to make it more trusted and provide our own stronger authentication on top of that assertion. Remember, the goal is to remove YOU from maintaining passwords for users while providing a strong authentication and improved experience.
To continue down this path of shifting the terminology, lets take a step back and look at a typical site registration (with strong authentication / MFA). You’ll usually have something akin to the below for the initial user registration flow.
The user will be prompted to enter their information, setup a login and password, setup MFA, then taken into the site. Then on login (when they return), they be taken through a similar flow to the below.
User is prompted to login and complete the MFA to complete their journey. Now, with both the above, this assumes 1) they remember their login and 2) have access to their MFA they originally used to register. In the event any of the above fails, or as compliance requirements change, this may involve high-touch changes and support.
Now, back to changing the terminology of Social integrations. When I talk to leaders, I shift the focus from using the social integrations as authentication to more and assertion of the identity of the user they can provide. Which, if you think about it, given the trust-worthiness of passwords, is pretty much what a username/password is providing today. Given this is just an assertion, and our goal is to implement stronger authentication and improved experience, once a user asserts their identity, we can layer in other options around validating their identity using identity proofing, profiling their device / location, and based on that, adding a strong authentication mechanism (some form of adaptive MFA, device controls, etc.). Then, on subsequent access to the application, if their device profile, assertion, etc. match (based on initial profiling), we can have a reasonable assurance for authenticating them (without ever prompting them). If something changes (e.g. new device, profile change, etc.) we can go back through a strong authentication process for the user with their initial assertion.
With this approach, we can start looking at the below type of flow for initial registration of a user.
We’re allowing the user in this scenario to assert their basic Identity information which can then be validated (against the person and device). All this gets added to the user’s profile so on login, this can all be used to build a much stronger, and improved, login experience like the below.
The primary advantages of this approach are going to be:
- You’re removing the biggest risk and attack surface by reducing password usage (can’t eliminate it completely, see below).
- You’re reducing operational overhead of maintaining and supporting passwords (self-service, changing compliance, etc.).
- Improving the assurance level your users given you have strong identity proofing involved in the initial registration and usage.
- Build trust with your users given you are improving security while reducing challenges associating with more security.
While there are a lot of benefits to this approach, there are going to be challenges you need to overcome.
- Need to understand you are building an integration with untrusted sources. Not only from a security perspective, there are public relations challenges with integrating / branding these types of integrations.
- There are data completeness issues. You may require some additional information beyond what the social provider publishes in their assertion (e.g. address info). Make sure in your validation phase of the registration you progressively profile the additional information you may REQUIRE for the experience with your application.
- You may be prompted by compliance and other groups regarding privacy concerns of collecting the data from the provider. You already have to collect the information, and the social integration provides a consent mechanism in the integration for the sharing, so this can be addressed pretty easily.
- This will not work for everyone. While you may get most of users want to use this approach and/or have social logins, there is going to be a good number of people who do not want to use this feature and/or do not have social logins. So, you will still need to maintain capabilities to authenticate using username/passwords.
The primary target of this type of capability is going to be your public facing applications / CIAM environment. But it may not be limited to that and could be used in B2B, employee onboarding (pre-hire type activities), etc. While I think this could be used for some employee type access (maybe high turnover / low risk type employee access), I think that is going to be a much harder sell and governance challenge.
This is not a perfect solution but given the challenges we have with providing strong authentication and user experience, this can be used as a tool to integrate in your environment.
