Good morning. Good afternoon. My name is Solenne Le Guernic. I'm a solution engineer at One Identity. And I will be joined in this session by my colleague Marc Maguire. We will tell you more about passwordless authentication for your workforce and customers. I know the word says it all, but passwordless authentication is not simply removing the password from a login flow. It's important to keep the security in mind. So we will start this presentation with some basis. And let's have a look at a quick definition.
Passwordless authentication is signing into a service without using a password. This is often achieved with certificates, security tokens, one-time passwords or passcodes, or biometrics. Passwordless authentication is generally considered more secure and user friendly than using passwords. So as I was saying, obvious, no more password. But still, security is a top priority. And to achieve this, we need to make sure we use the right MFA, multi-factor authentication, the right factor, the right security factor to achieve this securest authentication flow as we can.
So let's have a look at some benefits. And before that, let's compare password-based authentication and passwordless authentication, especially in a single sign-on scenario. So we know it now, more than 80% of breaches happen because of stolen or weak password. And this is simply because more than 70% of employees reuse password across personal and corporate applications.
We all have so many accounts, so many applications, so many websites we need to log in from. That is very difficult to keep up with passwords. I cannot remember so many passwords that are complex. If you want to use a complex one with non-related characters, it's very difficult to remember them all. Having a password management tool really helps, for sure. But it's not always possible. So that's why we reuse password, which makes it easier for hackers to breach.
In addition to that, cloud application requirements for password are pretty weak at the moment. You don't have the same rules as you have for on-prem application. So it's easy to end up with a very simple password when you need to authenticate for a cloud application. If we compare that to passwordless, the first difference is you don't have a password to remember, of course. But this means when you come back from holidays and you don't remember your password, you don't need to spend time with IT to reset it.
You can directly authenticate using one of the multiple MFA that you can use in a passwordless authentication flow. And if your administrator had been clever enough, they probably would have provided you with multiple MFA factors so that you have some failover. So in case you have lost one or forgotten one, you still have another one to login. So overall, the passwordless authentication provides a better user experience. So we've mentioned them already a little bit, but let's sum up the benefits that we can achieve with passwordless authentication.
No need for password means less chance for old password to be reused and then breached, less chance for weak password to be used to authenticate. It's going to ease the logging process overall. And especially for mobile devices, it's very difficult to type a long and complex password on a small keyboards. So moving on to passwordless authentication will simplify that, which provides a seamless user experience and is going to simplify the authentication process, removing the frustration for some of your users.
Now that we've talked about passwordless in general, let's have a look at the passwordless capabilities OneLogin can offer. Most of the features we have regarding passwordless are available in security policies. So you don't have to configure multiple things. Everything is in your security policies. We have both user and application policy to help you configure step-up authentication for some applications, for example.
The amount of security policy you can configure in OneLogin is unlimited. So you can set up different groups, depending on the jobs of every users, depending on their log-in behavior. You can adapt the authentication factor based on the user population the security policy will apply to. And we know that not every users log in the same way. Some are traveling, some are not. So it's important to make sure the right security policy applied to the right group of users. And then OneLogin can provide adaptability with the possibility to change security policy, depending on contextual factors, using Smart Hooks.
I will talk just a little bit about Smart Hooks because that's not the purpose of this session. But OneLogin as a vigilance AI that is going to calculate a risk score for every single connection using the contextual factors around the log-in phase, like the IP address of the machine, the time of the day, the geographic location, et cetera, et cetera. And depending on your users' behavior, that risk score might change over time. And you might want to change the security policy when the risk score is becoming too high to make sure they will have to validate a more strict MFA before they can access their application. And you can do that using Smart Hooks.
This is the list of MFA factor we have available out of the box. And they are all compatible with the passwordless authentication flow. So we have our own application called OneLogin Protect that supports both push notification as well as OTP code. OneLogin SMS can be used with any SMS provider. You can have a magic link in an email. And we can also use WebAuthn for biometrics with Touch ID on a Mac or Windows Hello on a PC, for example, but also FIDO2 card, et cetera, et cetera. We can integrate with some partners like Duo and YubiKey, but also with other OTP code application like Google and Microsoft Authenticator.
This is what the passwordless flow would look like in our security policy. So as you can see, it's very simple to enable. You simply tick the box and that's it. But still, we don't just remove the password from the flow. We can leverage other factor, like certificate or risk score, as I was telling you about before, to make sure the authentication remains secure. And this is an example of Smart Hooks. Smart Hooks are outside of the OneLogin UI. You need to download Postman collection that are available from our developer website.
And everything is pre-written for you. You simply have to decide, for example, for this specific Smart Hooks that will adapt the policy based on the risk score, you would have to select from what risk score you want the policy to be changed and to which policy the user should be redirected to. So you will have those policies set up in OneLogin UI. And using their ID, you can use the Smart Hooks to switch the policy for a more stricter one, in case the risk score becomes too high. Now I hand it over to my colleague Marc, who will tell you more about passwordless in a workforce scenario.
OK, thanks for that, Solenne. So now we're going to delve a little further into a Workforce-specific topic here on passwordless. So we've got some key considerations here we want to run through when we're planning and designing our passwordless solution for our Workforce use case. So first of all, we're going to really want to think about which authentication factors we want to leverage in our Workforce passwordless solution.
And so this will, you know, combine various factors that will be unique to your organization-- which kind of devices are available to people, you know, secure working areas, and perhaps mobile phones are prohibited, et cetera, all of the different considerations that, let's say, could be unique to your workforce environment. So as we said, we would recommend to put a lot of thought into this, you know, which authentication factors are going to work for your solution. And then from that list of the factors that you think will work for you, you need to select at least two of those factors.
And you need to make sure that, you know, these two factors are OK for everybody in the environment, in the planned project. From those two factors, then, you need to consider, are those factors usable from all working locations at all times? So this is something that obviously is critically important. So we need to make sure this is going to work for every user in every different working location.
Then consider, well, what's the scenario if only one authentication factor can be registered? And what are we going to do there in that case? And how can the support processes be updated to handle scenarios where, you know, users potentially lose that particular authentication factor? And how can they recover their account in that scenario?
So then we want to think about things around the transition. So how can we actually transition into our passwordless solution? So once we've actually designed what it will look like, what the configuration will be, what the components will be, now it's a case of how do we actually transition onto this desired state. So we want to think about here how and when will we allow users to manage their own authentication factors. So, under which circumstances and which kind of controls are needed around that.
How do we control the user experience, then, of migrating from password-based into our passwordless solution? So do we want to have this automated? Do we want to have an admin-driven approach? And how can this look? So there's a few different options there. Then, we need to consider things like our new joiner process then. So how will our new joiners be enrolled automatically into the passwordless solution once it has been implemented? So we have a couple of demos we can show how that can be done a little later on.
And then final thing to consider is how do we layer adaptive authentication capabilities over the passwordless solution that's been implemented. So this is adding even for other security controls around the passwordless solution and layering in things like risk and adaptive authentication. So some recommendations for everybody on this. So obviously, the first one here is pretty clear. So use phishing resistant authentication factors wherever possible.
This is obviously a big security benefit. And we have a number of different authentication factors that will meet that requirement. So then we recommend to categorize authentication factors that you intend to use in your solution into two different categories. So the first being our primary use factor and then our additional use factor. So we want to make sure that there's no dependency between the primary use and the additional use factor-- for example, they're not both based on the same mobile device.
So obviously that's not going to provide resilience if the user loses the mobile device. So you want to make sure that there is a segregation and different dependencies on the two different authentication factors you're using in your primary use and your additional use factor. We recommend, then, to consider leveraging external high trust identity providers where possible. And if you can use these in your use case and in your solutions, this is definitely going to help.
And then in terms of migration, actual moving to that passwordless experience and bringing it into life, we recommend to use our Smart Hooks capability where you can actually automatically migrate users into those passwordless security policies. Once the system sees that they have the prerequisite MFA devices, our authentication factor devices registered against their account. So this will allow them to automatically transition into that experience.
So then we want to determine which kind of situations the security policies with the additional factors enabled can be triggered. So these are scenarios maybe where you want to have a specific sign-in experience using the additional factor, rather than the primary use factor. Because perhaps, for example, the primary use factor is no longer available. So this sign-in needs to use the additional factor. And perhaps that allows you then to recover your primary use and re-register another authentication factor for your primary use factor.
And then if your passwordless solution will not meet all of the requirements for all users in all locations in your environment, don't abandon the rollout, but rather try and ring-fence your users into those that can be migrated onto the passwordless solution and those that can't. And obviously, if you can roll that out to, you know, the majority of your users that can benefit from this, well, then that's a value added from your security perspective as well as user experience. And so it's best to carry on and, you know, don't abandon the project just because you can't meet every single user requirement.
So now we've got some demos. So the first case here we're going to show how we can onboard a new user into a passwordless flow, in this case using Smart Hooks. So the new joiner has just been created on the system. And in this case, they have been created with email, magic link as a authentication factor. So this can be pre-registered by an admin on behalf of the user. And the first time they sign in, they'll be using the magic link. And then they'll be requested to register an additional factor, a stronger factor, passwordless authentication factor and use that going forwards, after that point.
So we can see here that the user's received their email to notify their account has been created. So that's been activated. So they can go to the login page and commence their first login. So in this case here, we've got our Cedar Stone environment. They entered they're username. And then we'll see here, they're prompted now for email, OneLogin email and a magic link, which they've been sent. And they can click the access link here to authenticate.
And they signed in now into the portal. And we can see they have, at the moment, no access to any resources, only the option to enroll in OneLogin Protect. So they can go ahead and carry out that activation process and register OneLogin Protect on their mobile device and they can pair their account to the mobile app. And you can see now, they're back in the app portal. So now at this point, they have registered an authentication factor with OneLogin Protect in the system. But they still don't have access to any corporate resources.
So if they log out again here now and log in for a second time, now that they've registered OneLogin protect, they will be taken into a passwordless experience using OneLogin Protect, rather than the email magic link. So they can approve the push notification and then they're signed in. And now at this point, they're given access to corporate resources because they have the stronger OneLogin Protect authentication factor enabled on their account. So that's just a case of how we can start off with one authentication factor in the passwordless flow and then uplift to a stronger factor and then use that factor going forwards then.
OK, so now we're going to look at passwordless from the customer and the CIAM perspective. So we've got again some key considerations that we recommend. You know, people are reviewing and considering these in their design of their passwordless solution. So first question is clearly which kind of authentication factors are going to be convenient for your users. So obviously, in CIAM here, convenience is obviously the number-one priority here, making sure those users will return to your service over and over again and consume the service in a convenient and also secure way.
So next question then is around security requirements. So of those convenient factors, you know, how many of those factors will meet the security requirements that you have identified for your solution? So then, we want to talk then about, do we need to have a different level or a tiering level of authentication factors in the solution? So do we have just a single set of authentication factors for all users? Or do we want to offer a stronger factors for, let's say, users that maybe have a premium subscription to the service or something like this? So these kind of questions need to be considered in the design phase, as well, of your passwordless solution for your project.
Then, how will the users manage those authentication factors? So will they be managing those factors in a custom interface within your application, which is calling our administration APIs to manage those authentication factors? Or actually, will you redirect the users into the CIAM platform to manage those authentication factors directly on the OneLogin service? So these are the considerations here from this perspective.
And then the last point here is around SMS gateways. So, you know, does the CIAM project have funding to allow for additional ongoing fees, obviously based on authentication, levels and volumes of traffic, so SMS gateways, SMS charges, et cetera? So this is obviously important to consider and make sure this is planned into the project from the start.
Some recommendations then, again, from the CIAM perspective, we definitely recommend that you use the hosted login page from OneLogin for your CIAM solution. Bringing in that passwordless experience, then, to your customers is simply a configuration change and not a single line of code needs to be rewritten in your application to bring passwordless experiences to your users. So it's simply a matter of allocating a user policy to a user. You know, that can be done either manually, automatically through mappings or through the API, as well. So lots of options there to just bring that to life for your customers once you're ready to do so.
Using the hosted login page, then, will obviously allow you to then bring Smart Hooks into the equation. And this can be leveraged, then, in your user flows and your journeys for authentication experiences for your customers, dynamically allocating policies to the users based on different contexts and really leveraging all of the information that's available to provide the most, you know, seamless and secure authentication flow for your users. Then, we want to again, we can show how our customized conditional logic around passwordless user policies can be triggered then with Smart Hooks.
So like I said, with all the context that's available, we can conditionally apply passwordless policies to users based on incoming authentication requests and how these requests are being processed through the system. We recommend to register an authentication factor that can be pre-registered as the first factor, so the first passwordless factor that will be used when the user logs in.
So there are a number of different authentication factors that can be pre-registered on behalf of the user without requiring any user involvement. And you know, these can give you a baseline of passwordless experience for your customer. And then as they sign in, then, to the environment for the first time, you can then ask them to register additional factors or stronger factors with a little bit of user participation to make this happen.
So we've got some CIAM demos here now to go through. So our first case here is around registering a user into a passwordless flow from the start and using email magic link. And then, like I said just a moment ago, once they sign in for the first time, we can ask them to, you know, register an additional authentication factor, which is going to be used then going forward. So in this case, we'll be using passkeys as that additional authentication factor.
So we can see here we have our Cedar Stone demo site here on our airline brand. So we're going to create an account here in our custom registration page. So we'll just enter our first name, last name, and our email address and do the CAPTCHA to complete the registration. And at this point now, the user will be created through the admin API and also an authentication factor will be registered against their account. And in this case, it will be email.
So that's all happened in the background. And the user can now go to sign in for the first time. And they enter their email address. And they'll be prompted here now that an access link has been sent to their email. So they can go and find the access link and click on the access link to authenticate for the first time into the environment. And we can see then they're prompted to set up a WebAuth and passkey once they've signed in for the first time.
So they go and do their biometrics on their device and register this WebAuthn factor against their account. And now they're signed in then to this CIAM application here. We can see some of the claims. And the user has been signed in. So now if we sign out and sign in again, we should, again, leverage the passwordless experience. But in this case, we'll be using our passkey or our WebAuthn factor rather than the email magic link as we saw.
So we can select now passkeys. And we can do our biometrics to sign in. So we now have two options available to sign in to this service, both in the passwordless flow, so with our passkeys and our email magic link. So that's just a little example there of how you can start off on one authentication factor and then uplift to another one once the user has signed in.
OK, so our second demo, then, is showing how we can migrate a user from Okta Auth0, in this case, and move them into OneLogin and migrate them to OneLogin and transform their experience into a passwordless experience pretty much all in the single action of migration as well as transformation. So you can see here, I'll just do a quick search. This is in the Admin Console here. We can see do we have this user. So we can see this user doesn't exist already, so another.customer@gmail.com.
So if we go now to our CIAM application and go and initiate sign in, we can go to our sign in page. And we're now redirected into our hosted login page here. So if we enter our username and password here now, we'll make a call to the existing CIAM solution for this environment, which is an Auth0 environment. And we'll validate our username and password. And we can see now the account has been created.
You can see here on the fly, our John Smith under our customer account has been created. And we can see here some mappings have triggered. And we're now signed in. So now we have the optional prompt to set up MFA. So we're going to set up a passkey in this case here and use our phone, in this case, to store our passkey and scan our QR code here. So if we scan the QR code and register now a passkey on our mobile device here, we can save the passkey and do our biometrics on the phone.
And this should then basically add this authentication factor to our account in this Cedar Stone environment. We get our terms and conditions down here, which we can accept. And now we're signed into our Cedar Stone retail application here. It'll open in just a second. You can see now we've signed in and we've got our user details here and our claims and the ID token. So we can sign out now.
And at this point, obviously the user has been migrated into OneLogin from Auth0. And we can see that WebAuthn was registered against their account. So now that we go to try and sign in again, we'll be taken through a passwordless flow, so using our Passkey. And we can scan the QR code here and use our passkey on our phone and basically share the passkey then onto our desktop device here and sign in to the application here.
So we no longer are using passwords that we migrated across from Auth0. And here it's a fully passwordless experience now to sign in for this user into our Cedar Stone retail application now going forwards. So that's just a really nice way of migrating a user from, you know, Auth0 into OneLogin and then transforming their experience to become a passwordless user, pretty much all in that single transition.
OK, so now we're going to have a little look through some extensibility capabilities here and extending your passwordless solution out into external vendors that are existing in this space. So we've talked about already some of the different authentication factors that are available for your passwordless solution. We've seen things like OneLogin Protect, OneLogin email with magic link, and passkeys, WebAuthn, et cetera. So now we're going to just little have a review of our Trusted IDP as a factor, which is a new capability that was added to the platform earlier this year.
So with this capability it allows us to integrate into any external facing, any external system that supports the OIDC protocol. So with this, we can use any external system then as an authentication factor in your passwordless solution in your OneLogin implementation. So we can see that we can consider things like identity proofing vendors, password passwordless specific vendors that are maybe doing things with biometrics, you know, voice or facial biometrics, et cetera. We can use things like government e-IDs, decentralized identity vendors as well.
And we've got a list here. You can see a screenshot then from my environment here where we've successfully tested and integrated into all of these different solutions there. So we can basically bring in an external passwordless solution into your environment and use that, then, as an authentication factor, just like you would use any of the other built-in factors like OneLogin Protect or YubiKeys or WebAuthn, for example. So just to show how this looks. So you can, you can see here, we've got one example, in this case, a MATTR, which is a decentralized identity vendor.
So we've got the Trusted IDP as a factor created there, you can see. We give it a name. And then we link the authentication factor to one of our Trusted IDP connections that we've built there to connect to the OneLogin environment to that external system. And like I said, you need to be supporting OIDC to make this work. So we can see then in our user policy, then, it's simply a case then of identifying that OTP authentication is required and that we're going to use the MATTR authentication factor in this case and then obviously allocate this policy then to the relevant users. And they will be able to use this authentication factor then in their passwordless experience.
So we've got a demo here just to show this redirect to an external passwordless solution and how this looks from a user experience. So we can see here, we have our login page here. And on this case, we're going to sign in as our John Smith user. So John will be using an external passwordless solution. And we get a redirect here now to our MATTR verifiable credential solution.
So we can see we have a QR code to be scanned here. And we can scan this QR code, then, with the MATTR mobile app to share our verifiable credential, in this case, with our OneLogin implementation. And we get redirected back now and signed in to the portal. So this is a passwordless experience and like I said, using an external system as that passwordless factor.
So we can see here, in this case, the authentication factor has been added there as MATTR. And the user's logged in and signed in there. You can see some more details around how that login looked and when it went through. So this is just showing, you know, the redirect to an external OIDC system to perform the authentication, and then being redirected back into OneLogin to go through a passwordless user journey.
We can show then our second demonstration now where we can actually bridge two different external passwordless solutions together using OneLogin. So again, in this case, we have our test portal here. We can sign in with, in this case, our second user is jim.smith@abc.com. So our first release factor will be sent to our BankID implementation here. So this is a BankID and Norway test environment. We can see we're going to authenticate with our BankID here, our username and our BankID password.
And we can consent then to the attributes being sent to OneLogin. And then we get signed in. And now we want to actually access the application, the particular application here. And at this point, then, we get redirected to a second passwordless vendor. In this case, we'll be doing our verifiable credential example again here, where we scan the QR code and share the verifiable credential on our phone to authenticate.
And then this will redirect us back into our OneLogin environment here now, and ultimately into this applicant's application here. You can see in a moment, we landed into the application here. Now we logged in and everything is working fine. So this is just showing how you can use two different external possible solutions and bridge them together using OneLogin and using our user security policies and app policies and using this Trusted IDP as a factor capability, which was just launched earlier on in the year.
So now just to talk a little bit about, if you've any CIAM projects that are not using the hosted login page, but using our APIs, we can also offer a passwordless solution for those cases. So let's say you've got your customized login page and you just want to leverage OneLogin here for a passwordless-based solution. So we can support that with our MFA API here. So we can see on the developer site there, you can check out this multi-factor authentication page and a nice overview. And just to say, so there's limited authentication factors are available, but it is still very much possible to bring passwordless authentication into your customized same login page as well.
Thank you, Mark. And we've discussed with our professional services team to get their feedback on what are the challenges our customers are facing when moving from password authentication to passwordless. And so we thought it would be important to give you some practical steps to follow if you want to move to passwordless authentication.
So those are the four steps we came across and that should help you get a smooth transition to passwordless. A pre-step that is not mentioned here and that comes directly from the feedback we got from our professional services team would be to make sure to register an MFA factor to every users that you want to move to passwordless. This is a big challenge for our customers when moving to passwordless. Because if you don't have an MFA factor registered, then it might be difficult to move to passwordless. So I would say, make sure to register an MFA factor to all your users.
But also, you need to think of a way to onboard users to passwordless flow directly and not moving to password first. So there's different ways of achieving that. You can use smart hooks that I was mentioning before. But there are other possibilities. And we would be more than happy to discuss them with you if you are considering moving to passwordless.
Then, after you have registered an MFA factor to your user's profile, analyze your user population. It's important for you to know your users' habits, their log-in behavior. Where are they generally logging from? Are they logging from home? Are they traveling? Are they logging in in a warehouse, et cetera, et cetera? This will give you an overview of the associated risks around their login and gives you a better overview of all your users population.
Then, define the population. We understand that passwordless authentication might not be good for everyone. So it's good for you to define the users that would benefit from passwordless authentication. Then, test with a small group of users. It's easier to get some feedback when you have just a small population of users selected. And it's easier to correct if you just have some users impacted with that change of authentication flow.
Maybe choose the users that are more IT savvy, the one that will not be so affected by a change and that would be able to provide you the better feedback. You want to make sure you correct all those little mistakes or you change all those little settings that can make your users' life difficult so that when you're ready to move to production, everything is set up as you wish. You might have forgotten something. And this small group of users that is testing for you will help you to correct those.
And finally, when you're satisfied with the testing phase, move to production. You should have corrected all the settings that you wanted in your test phase and production move should be smooth and seamless. So yeah, those are the four steps that we recommend for you to move from password to passwordless authentication. And we hope those steps will help you in having a smooth transition.
We are reaching the end of our presentation. But we've added some additional resources in case you want to learn more about passwordless authentication. And there is a webcast, an e-book, but there are also some blog posts that have been written by some of our colleagues. So feel free to have a look at those articles if you want to learn more. And then if you have extra questions, then feel free to reach out to us. We'd be more than happy to answer your questions, but also provide you with some demo if you want to see a passwordless authentication flow with OneLogin Live. Thank you for your attention and have a nice day.