Okta Security Roadmap

Alex Bovee: Welcome everyone. I really appreciate everybody coming out today. My name’s Alex Bovee. I lead Product Management for Security Products here at Okta and I’m excited to tell you about where we’ve been and where we’re going to. I’m joined by Sami Laine.

Sami Laine: I’m Sami Laine. I’m the Director of Product Marketing for Security Products here at Okta and I’ll going to be showing a little bit of where we came from and then showing a little bit where we’re going.

Alex Bovee: Great. They make us put this boiler plate in front of the presentation but this is roadmap content, so just be advised that these are forward-looking statements. Before we do get into that, I wanted to touch a little bit on where we’re coming from. This last year was pretty exciting from an adaptive authentication standpoint.

Hopefully, we’ve got a lot of adaptive auth customers in the audience. If not, you should take a look at it. But we shipped a lot of great features that, I think, really start to get us more adaptive capabilities when it comes to authenticating users things like new geolocation detection, new IP, new device, impossible travel is a beta that we currently have today available.

Hopefully, what you’ll see as we go through this roadmap presentation is really how this context in these signals start to really form the basis for a powerful engine that allow you to reduce friction and improve usability for your end users. This is just the beginning. We’ve made a lot of advancements this year, but I expect that a lot of these stories and capabilities are going to be coming together holistically this year to just create awesome experiences for your end users that are very secure.

Also this year, we really focused a lot on improving our existing MFA integrations and adding new surface area to our MFA product portfolio, so things like supporting AnyConnect VPN natively through our OIN, you can go into our Okta Integration Network today. You can find a plethora of VPNs that are support over radius, great documentation linked off from those VPNs in terms of how to set them up, configure, deploy them and scale and the best practices associated with that.

We also launched support for our Active Directory Federation Services. If you are using ADFS on prem as your IDP for single sign-on, you can still leverage Okta’s best of breed MFA solution and use it in that context as you think about and consider whether or not you want to move to the cloud for identity.

Just to kind of round this off, I think the other point that I just want to bring home is that we’ve also, the team has been super hard at work just building lots of great security features across the board. We’ve shipped improvements to SMS deliverability, radius capabilities, new MFA integration service area, new factor experiences, really across the board. I’d encourage you to definitely talk to your CSM, look it up to his website, look at the features in our documentation and just sort of understand what’s available today because there’s a lot there that you may or may not be taking advantage of within your tenets today.

Without further ado, I’m going to hand it over to Sami and he’s going to do a little bit of a demo, just around some of the functionality that’s currently in production.

Sami Laine: All right. For all those folks who are still streaming in, if you’re standing back there in economy minus, there’s still business class free upgrades available here in the front row. Come on down, so you can see a little bit better.

I wanted to focus on a couple of things only of all the things that we shipped this year because if you need something like, for example, the Palo Alto integration or a Citrix integration, you already know you need it, so you’re going to go and get it and find it. But I’m going to show you a couple of things that you may not know that you need but I encourage you to take a closer look at.

We have a couple of things here in early access specifically around behaviour detection that I wanted to highlight. These are the things that make it possible for you to create now new differentiated policies that look at the context of the access itself.

For example, if a user comes in from a net new device, that user has never seen from before, you can create a specific policy for that. That policy allows you to then say, I create a behaviour detection rule and then I can go in and create an authentication sign on policy, for example, that takes that rule into account. Similarly, I can create policies around the user’s IP address and I want to show you something else, also user’s location. You can, for example, say that ... I want to say, “Are you within 50 miles or 80 kilometres of the same place that we’ve seen you before?”

You can do this based on the actual locations where the user are coming from and start creating a behaviour pattern on where this user normally logs in from. If they’re not at home or at work, or at the Starbucks where they go to escape from work, to take a vacation from their desks, then you want to know about that and challenge that user potentially with a different challenge at that point.

You can create these rules here and set the actual radius, say, let’s call this 80 kilometres, 50 miles. We’re using kilometres of course because we’re civilised. We evaluate this against how many authentications you want, let’s say last 40. Now, I can save this rule and I can then take that rule into my authentications sign on policy. On my sign on policy, for example, for my administrators, I can create that new rule and now say, “Behavior,” and look at that location that I just created and add that in.

This makes it easy to create graduated rules that really show what is the actual risk for this access and take that context of users access into account. There’s many more things that we’ve done that might be interesting, another aspect of this is also, I want to highlight for you, is we now have available to you things like detecting whether the user is coming from a anonymiser, if they’re coming from a proxy, maybe a Tor network mode, maybe a VPN provider or something like that. You can create network level policies for those.

These policies, like we show you last year, don’t have to just static IP addresses of known corporate networks, they can also now include country level things. They can include dynamic things like anonymisers, et cetera,

With that, I wanted to then bring it back to Alex and we’ll go into the future.

Alex Bovee: Thanks Sami. Great.

I like to kick off the security roadmaps and if folks in this room have been to the previous security roadmap that I’ve given over the last couple of years, you’ve probably seen this diagram, albeit, it’s prettier this year because we spent some money updating the slide. But the reason I continue to go back to this is that I really do fundamentally believe that this is, it’s the crux of security from an end user standpoint. It’s all about tradeoffs and it’s about tradeoffs between usability, security and deployability.

Okta offers a wide range of policy configurations and capabilities and authenticator experiences that allow you to strongly and securely authenticate your users but at the end of the day, there’s just trade-offs associated with these different authentication experiences in terms of how you can deploy them. Is it hardware based, is it knowledge based, what are the tradeoffs associated with that and what’s the security profile of how you can authenticate those users.

Keep this in mind, but I think, what I’d like to do at the end of this is hopefully bring it full circle and show that a lot of the investments that we’re making, we’re actually trying to blow this up a little bit. We’re trying to get to the sweet spot of where you can actually achieve better security without the same usability trade off, without having to add friction into the security experience for your end users. We’ll talk through what that means.

We really think about our security roadmap in terms of three pillars of investment areas. One is around securing everything. The second is around factors, enrollment and recovery. Increasingly, this is a really important area for our customers, thinking about how you securely bootstrap your users into new credential enrollments and then the third is around adaptive authentication. How do we use those experiences to reduce the friction for authenticating your users and securing your users.

Let’s jump into secure everything first. This is probably one of my favorite slides in transitions in this presentation. But suffice to say, Okta was really born and built in the cloud. Everyone knows us as a leading IDaaS vendor. We’re neutral. We’re sort of the Switzerland of integrations. We’ll work with many different organisations and partners and technologies and really our goal is to try to connect that all up, particularly as it relates to our MFA and our strong authentication solution.

We recognise that customers are on a journey. Customers are on a journey from their on prem solutions and investments and environments to that cloud world and at the end of the day, you can’t just end of life everything that’s on prem. You can’t completely transition away from your VPN or you can’t maybe ... You still have to protect those one prem resources and capabilities and so, we’ve really been focused on helping our customers bridge those investments.

Take our Okta Adaptive MFA product capability, take that best of breed cloud-based MFA solution capability and bridge that to your on-prem environment, whether that’s supporting your VPN, supporting your on-prem servers, whatever it might be. We want to make sure that we can help you transition and continue to leverage it as seamlessly as possible what you’ve already invested in.

With that in mind, we’ve bucketed these integrations in four categories. These are things that you’ve probably seen us make progress on previously but then, we’re continuing to invest in all of these as we move forward as well.

The first category is on-prem IdPs. We recognise that a lot of customers aren’t going to necessarily modernise their iPDU right out of the gate. They’re not going to move to the cloud for identity necessarily. Some customers will and that’s great. A lot of our customers have historically done that and that’s awesome but at the end of the day, sometimes you need to support that hybrid scenario. Maybe the key requirement for you is solving a phishing or a compliance problem and you want to go with Okta’s MFA product to solve that problem, but you don’t want to necessarily wrap that into an SSL project right out of the gate or you don’t want to take your IdP and move it to the cloud.

In that case, we want to support you in that model. We’ve been working to integrate with some of the traditional on-prem IdPs to help you bridge that gap and maintain that existing investment without having to modernise or change all of your investments overnight where you can, instead just adopt that MFA product out of the gate. Today, we support Active Directory Federation Services as an MFA plugin capability. We’re working things like ... We’re working with Ping and Oracle as well to support adding MFA to those solutions.

The second category is VPNs in network-based environments. Things like Palo Alto networks, Cisco VPNs, really what we want to do is make sure that tier one-supported experiences so that you can go to Okta, you can discover them on our integrations network and that you can seamlessly add that and deploy Okta MFA alongside those solutions.

The third bucket is just independent software vendors. Folks like Epic, particularly with the e-prescription solution, we want to make sure that you can use Okta’s MFA solution in some these point ISV-centric solutions.

The fourth bucket is for machines and infrastructures in servers. Things like supporting remote desktops. Maybe you have a compliance requirement or on PCI compliance, you need to add 2FA to your remote servers. Maybe you’ve got Unix boxes on-prem or on the cloud and you want to add 2FA to that. Okta’s been making investments there to allow you to add strong authentication to your machines.

Along the lines of the MFA-only third-party IdP integrations, again, we want to make sure that we can help you transition as seamlessly as possible and continue to leverage that on-prem investment. Again, the focus here is really around interoperability. We’ve built a plug in for the AD FS environment. We’re working on additional integrations with Oracle and Ping as well.

Touching a little bit on just overall, as well, our really thought process on these MFA integrations and particularly, I think, with respect to some of the VPNs in network-based integrations is we really focused on making integrations that just work. Really, streamlining that experience. Before with Okta, you could add our MFA experience to your on-prem VPN, but it might require a lot of lifting up the hood and trying to figure out how to connect those technologies together to make it all play well together. But really changed that experience and it started with the OIN, it started with great documentation.

Today, you can actually open up our application catalogue, you can search for Palo Alto networks VPNs, you can find the RADIUS-based VPNs, you can find the SAML-based VPNs, you can find Cisco AnyConnect VPN. You can add that to your list of applications, you can assign users to it, we link off to documentation. That documentation has been vetted and created in a test lab environment and we’ve got great screenshots that actually walk you through here explicitly, not only what to do I in Okta service but what to do in the actual technology that you’re trying to connect with our service. We’re really focused on trying to hand hold and make sure that you can get up and running as quickly as possible with those additional integrations.

With that in mind as well, they’re also fully supported. We have a support team that’s able to spin these environments out in the labs so if you run into an issue, if you’re having trouble getting something configured, we can actually support you on that journey. Again, with Okta, the goal is really just to make this as seamless as possible and to just make things work as easily as possible out of the box.

The fourth bit, in what underlies all of these investments is really our underlying infrastructure and our platform approach for actually adding MFA to different technology service areas. We’ve invested in a developer toolkit and capability that allows you to add MFA to any application. This is actually what we’re building all of our integrations on. What we’ll do is we’ll expose that to our customers.

Let’s say that you have a ... let’s say on-prem application that you want to add MFA to. Maybe it’s not available in our integration network catalogue. It’s not something that we support from a first-party experience, but you really need to protect that application, you can easily grab Okta’s developer toolkit, you can leverage our OIN to add a custom integration and you can just hook that right up into your application and leverage off the strong authentication capability within that existing application.

Alex Bovee: So again, the goal here is just to make sure that we seamlessly support all of your infrastructure, your technologies, and we make it really easy to add our strong authentication capabilities to all of your technologies.

And just to close this out, kind of where we’ve been and where we’re going. This year, particularly last six months were big for us in terms of shipping some of these new integrations. So we shipped Cisco and Equinix, Citrix Netscaler, radius based support, Palo Alto networks, Microsoft ADFS. We have a credential provider for most desktops.

So if you need to protect remote servers, you can do that today using Okta’s MFA product. And then in the future, we’re just continuing to push that forward.

So continue to look for great things for us. Or great things from us. And let us know if you have interest in additional integrations that we’re not covering. We’d be happy to chat with you about that.

So that’s really securing everything. Again, it’s taking our MFA product capability and making sure we wire it into your environment, making sure that we can help connect all of your different technologies together and all the different surface area of your networks, machines, devices, applications, whatever it might be.

And to leverage Okta in those scenarios. The second area that I’m super excited about is factors, enrollment, and recovery. So increasingly, as you think about the security landscape, step one is how do you make sure that you’ve just prevented things like broad-based phishing attacks and credential breaches using strong authentication capabilities.

Really, the problem statement begins to shift and change to, how do I strongly enrol the user in the first place? How do I make sure that I secure the recovery so that someone can’t be socially engineered through the help desk from a recovery standpoint?

So we’re starting to focus on how we solve these problems to make sure that we’re addressing the weakest link in the daisy chain because pretty soon, particularly when you get to pass through those experiences, the weakest link in the daisy chain is actually the recovery and the enrollment process in the first place.

So we have to make sure we solve those problems. This is a little bit of a slide I like to use just to talk about the importance of thinking about some of the different assurance across some of the different factor experiences that we support.

So Okta, we made a lot of investments over the last two years to support a wide range of different factor type experiences. From the low to the high assurance modes. And this is very important in the context of that initial slide I showed balancing usability, security, and deployability.

Because fundamentally, each of these different factor experiences has very different attributes across those three dimensions. So things like security questions and passwords, incredibly usable. I don’t know anybody who doesn’t know how to type in a password.

We’ve been pretty programmed to be able to do that through our lives. Pretty deployable, meaning an application developer knows how to deploy those and use those. From a security standpoint, I think we’ve all realised they’re not particularly the greatest because they can be written down on a piece of paper and put on a laptop, or they can be phished, or they can be told to someone.

That being said, I think there is a place sometimes for lower assurance credentials, particularly as you think about the security and the risk profile of the users who are authenticating and maybe some of the constraints that you might have around different populations of users.

Maybe the users don’t have access to mobile phones or hardware devices or it’s cost prohibited to be able to deploy some sort of a hardware or token based solution for authentication.

The point here is that we’re really supporting that wide range of factor experiences and so when you take this and you look at this in the context of our adaptive authentication capabilities, hopefully the story start to come together in terms of how we’re blending those contextual signals with the factor and the assurance with a different factor experiences to get the right level of assurance for your authentication.

On that note with the factors, one of the ways that we’re maturing the factor experiences is really looking at genericising some of the different factors that we support today.

Today we have a Google authenticator factor type which is really a TOTP based implementation. But we want to make that a generic TOTP based experience from an admin and an end user experience.

We want to allow you to procure hard tokens from a vendor if you’d like to, that uses standard TOTP based algorithms for generating the one time passcodes and actually import those seeds in secrets into the Okta admin panel.

Provision those tokens to your users and help you use those hard token experiences with third parties, if that’s what you wish to do. So we’re investing in genericising that experience.

Similarly, and this is a theme you’ll see across our factor experiences, is really taking them and moving them forward in terms of being able to leverage them across different surface areas. Similarly, what we’re doing is, we’re taking our Okta Push Verify experience and also making that a generic push experience where you can do an out of band based verification of a little piece of data, anon using the push channel.

So this is something that we’ve internally called a Okta Push Verify SDK experience. But really effectively what we’re doing is we’re saying that Okta Push Verify is an implementation of a push verification, out of band based verification via the Okta service, just using our native Okta Verify application.

But there’s no reason that we can’t allow you as a customer to instead of pushing that to the Okta Verify application, push that to your consumer mobile application or your partner application or whatever it might be, to do that push verification in a branded way through your website.

So this is a scenario that we hear a lot, particularly from our platform customers who want to maintain a branded experience, or want to be able to do transactional verification to their existing surface area, their existing mobile surface area for their end users.

Another area that I’m particularly excited about is around web authentication in FIDO. How many folks in the audience have heard of WebAuthN?

Okay, quite a few. That’s awesome. And how many folks have heard of FIDO? While I’m at it, how many folks have deployed U2F in production? This is just more personal interest.

In Okta, we are super aligned on FIDO. Many times, I’ll get questions that say, what do you guys think about FIDO? Do you think this is the right pattern? Do you believe in it? Absolutely.

What FIDO really did, which I think is super interesting, is it abstracted the verification of the credential with the relying party, which is Okta, from the authenticator experience itself.

It means that you can bring a strong authenticator like a Ubiquiti, hard token, to the Okta service. You can self-register it with the Okta service and then you can verify it for step up authentication.

And that verification is very powerful because it’s origin bound, which means it can’t be phished. So that means if someone tries to phish our users using Okta dot bad guy dot com or something like that, and actually tries to do the verification and then replays it against the Okta service, it’s not going to work because it’s bound to the bad guy domain, not the Okta domain.

More importantly, and what’s really exciting, is that WebAuthN actually started this. All of a sudden these problems of external authenticators, as well as on device authenticators.

So we’re starting to see a really robust ecosystem evolve around how do we build in strong authentication to hardware devices in particular?

So Windows Hello I think is a great example of an on device based hardware authentication solution using a biometric to unlock a private key in the TPM that can be used to verify the user up to the Okta service.

And even in that scenario, if you’re using a pin code to unlock Windows Hello, 1 2 3 4 5, the reality is that from a security perspective, it’s much, much, much better because the only attack that you really have to try to hack that user is to physically steal their laptop and then to guess that pin code over and over and over again.

I’ve said this before, I’ll say it again, as an industry, we’ve reduced the attack surface on our customers to physically stealing phones and devices. That’s a pretty good security model to have at the end of the day.

What we want to do is, we want to solve these broad based phishing attacks, we want to solve these broad based credential theft attacks. And so, WebAuthN helps us get there.

Furthering that as well is how we take our factor experience and make that more generic. So we’ve heard a lot of customers say, how do you interoperate with this identity proofing company? Or how do we create a better integration over here? How do we support multiple security questions, or whatever it might be.

Okta supports native factors today. We do integrate with third party MFA solutions so if you’ve got your own MFA solution, we’ll work with them.

The question for us then, is how we interact with sort of third party authentication and identity proofing solutions scalable. How do we build a platform that allows you to integrate those solutions with the Okta product?

So this is an experience that we’re calling Custom Factor Experience. And what this allows us to do is to make a call out via SAML or OIDC to a third party authentication solution and then use that for step up authentication, or use that anywhere in the Okta product that you would use a factor experience.

So when you think about how we start to solve things like credential enrollment, maybe you’ve built a home grown knowledge based authentication solution that checks the last four digits of someone’s social security number who their manager has had some mark flow or whatever it might be.

You can take that experience, you can build it, you can use it in the Okta product to bootstrap the credential enrollment  and recovery process. Now you’re starting to see how we’re really trying to solve that secure enrollment and recovery solution by allowing you to drive maybe higher assurance, more identity proofing driven requirements during the enrollment and recovery experiences.

And/or just mix and match those throughout the Okta product. So be able to use this maybe if the user forgot their mobile device. They can use that experience to do step up authentication to the Okta service.

It starts to unlock a lot of really powerful scenarios in terms of using Okta as a platform for authentication, leveraging our existing workflow experiences and policy frameworks, pulling in third party authentication solutions, whether those are off the shelf providers or something that you’ve homegrown.

I’m personally super excited about this and some of the scenarios that this starts to unlock for our customers. This just touches on that a little bit more. We really want to solve, again, that identity proofing, enrollment, verification, and recovery process.

And doing it in a scalable and a secure way. We’re also starting to think about how we need to evolve the policy framework around credential enrollment management in particular.

And so do things like targeting specific applications and whether or not you can enrol if you’re accessing those applications, how often and when we should prompt the users to actually enrol in credentials so you can drive that mass credential, that mass MFA, roll out problem statement for users at large, and then obviously, the identity proofing capabilities that I just mentioned.

The last thing I want to touch on is around adaptive authentication. Adaptive authentication, we like to think about in terms of, first we frame it up in terms of contextual access management. Contextual access management is just a fancy way of saying, let’s look at all the different context coming in around the authentication and then let’s drive the right security requirements to authenticate to Okta service based on that context.

You’ve seen us make investments around network contexts. Things like network zones. You’ve seen us make investments around location context. So we can do geographic based policy decisions, locations you’re logging in from.

We can do new location detection. You’ve seen us make investments around device context or device trust feature. We have a new device detection feature. We actually fingerprint devices now from the browsers, send that to the Okta service and build a behavioural profile around those users and the devices that they’re authenticating from.

But what we’re doing with all that context is, you can build static policy on it today. But eventually, we also want to make that easily consumable from a risk standpoint.

So, we’re going to take all those features, all that context that we’re building and pulling out of the authentication context, and we’re going to deliver a risk or a capability that allows you to say, look, I want to get a single score and say, if the user’s authenticating and it seems to be very risky, doing x.

Hopefully a lot of folks heard about the Okta thread in site feature that we launched today. I’m personally very excited about that feature. That’s a part of that story as well.

And to tie this all together, you’ve got the context from the authentication. What we want to be able to do then is drive that adaptive response.

So today, what that adaptive response looks like is prompting for a second factor, or allowing or denying access. But what we’re announcing today at Oktane and where we really kind of change the game is around this custom factor sequence capability that I’ll talk about in a second here.

Just to double click a little bit on Okta threat insights. I think this is such a natural story for us to tell. The reality is Okta is a service. We see it taxed across thousands and thousands of customers and billions of authentications among consumer websites, enterprise sites, the whole gamut.

And we see broad based phishing attacks, password stuffing attacks, credential theft attacks, the whole gamut of credential based attacks on our service and we have this intelligence and what we want to make is that intelligence accessible to you as an admin, to make smarter access decisions on.

So eventually we’ll fold that in the risk score. You can also use that in a static policy. And then you’ll be able to use that to drive the adaptive response capability.

On that note, with adaptive response capability, really the goal is to split the access management policy into two pieces. You have your context pieces that I just talked about around location, IP address, device, risk, threat signals, things like that. And then instead of just saying step up or deny or restrict this session link, really what we want to say is, the risk that we observed from this user is low or high. How do we need to authenticate this user in a way that makes us feel like we’ve ameliorated that risk? We’ve addressed that risk from an insurance standpoint with the credentials that they’ve presented because the credentials that they presented are secure enough to prove sufficiently that they are that user, regardless of what the risk actually is. This is a feature that we call factor sequencing, it helps power password-less experiences today. We had a password experience that we actually demoed in Okta today and what’s great about it is that it actually allows you to completely mix and match those factor experiences in Okta. So maybe if the user’s authenticating in a high risk scenario, you’re going to require you to factor and then a password as a second factor. If it’s a low risk scenario, maybe you can just ask for a password. Whatever it might be, again, you kind of mix that context and then drive the policy as you see fit.

With that, we’re going to pass it back over to Sammy to actually demo the factor sequencing feature.

Sami Laine: Let’s take a quick look here at an organisation where I’ve turned on this factor sequencing capability. I have here, an engineering group within my work and I set up a policy for access from different kinds of locations requiring different factor sequencing. So, for here, I have a different policy coming from anonymous access if I’m an an onymous network, if I’m coming from a VPN or something. Different one for outside of the headquarters and one inside the network, inside the headquarters. It results in different user experience.

Let’s take a look at that. I’m here as an engineering BP. I’m about to log into my system, but I’m actually coming from an airport WIFI and I’ve turned on my animalising VPN so that I can be secure in this high threat environment that I’m logging in from. You notice that I only see the discover style log in page here where it’s simply a username that I’m being prompted for.

When I click “next” the factor sequencing will then determine my context, where I was at the time, what network I’m coming from, and realises that the right policy here is to ask for something secure. You’ll notice that I’m not being prompted for password, I’m prompted for a U2F security key for either token. The reason we’re doing this, of course, is this allows us to limit and expose any kind of password guessing or any annoyance like getting random people trying out user access and sending SMS as the legitimate user for push notification. I’m going to start with something here that’s strong.

With that, I’ll just reach out here into my security key pocket. If you wonder what that small pocket here in your jeans is for your security tokens. Little known fact. I’m going to plug that in here and authenticate and now, since it’s a high threat environment, it’s also wants me to do the push verification. I’m going to send the push here and when the push comes to me, I can simply approve it from here. Of course, I’ll do it from my watch because it’s 2018 and we’re not animals, right?

Then, only at that point, when I’m verified, will I be asked for my password. In this particular case, since I’m outside the network, I’m still doing that final step. I’m going to require the password to be typed in and ... let’s see if I still remember Heidi’s password here... and it logs me into the portal. Alright. So what if Heidi comes to the office? What kind of experience would you expect there?

If I log out here, and I log somewhere from my VPN, while I’m at it, when that VPN connection is no longer there, then what I can do is I will reconnect here. Let’s see, my VPN should be off and if I type in Heidi username here. Click next, now that I’m in the office network, it simply, automatically, sent the push verify to me. I’ll accept it here. Approve. I’m in with a password-less flow because now I’m in a protected environment, network, with a recognised device, with a recognised authenticator and I’m allowed in and I have, now, full access to all the assets and not the limited access I had from the animalised network.

Alex Bovee: I’m going to clap for that.

Thanks, Sammy. I actually didn’t realise that’s what that small pocket was for. Mine is for collecting lint. Yeah.

Hopefully, at this point, what I’m hoping that everyone sees is strong authentication capabilities, a mixture of different authenticator experiences forms low assurances to high assurance modes. With a mixture of usability, security, and deployability tradeoffs. Context, being able to understand more about the user and the risk associated that authentication. Then the ability to respond to that context with a mixture of those authenticators to make sure that you’re securely authenticating that user.

The story there is that we’re going to ... Instead of always having the most heinous security experience, where you have to do step up authentication every single time with multiple factors or whatever it might be, maybe you reduce that security requirement in certain scenarios and you step up that security requirement in other scenarios to only the high assurance factors.

With that in mind, really the goal is to enable more secure end user experiences at the end of the day. This is around modern password-less authentication, is really the goal for this. At the end of the day, sure you can use things like security questions or a hard token for a password-less experience, but what we really want to converge, from an architectural standpoint, is moving that password-less authentication experience to more of a crypto-based experience. Ideally, out of band or in a non-fishable way.

In this world, Okta’s the service provider. We’ve got some sort of a public key associated with the authenticator that’s been registered for the user. That challenge experience is sent online down to that authenticator, where the user is doing a presence or a biometric-based verification to unlock that key to sign the piece of data and send it back. Fundamentally, that is our Okta push verify architecture. It’s using a cryptography-based verification out of band from the web channel so that it can’t be fished. That’s FIDO, U2F tokens, that’s web authentication at the end of the day.

We want to help our customers move to that through a combination of supporting the standard, supporting the diversity of factor experiences, and then supporting the policy framework.

Lastly, and just to bring it home, I think, at the end of the day, security is also about end user enablement as well. We have made some investments over the last year just to step up the amount of visibility that end user have into the security profile. Things like new device notifications, as I mentioned previously, we’re actually ... we now fingerprint all of the devices that authenticate to the Okta servers. When those fingerprints are set up, we can do new device notifications based on the finger print to the end user, letting them know that an authentication has taken place from a new device.

At the end of the day, when I think about security, you can always authenticate users as strongly as possible, but the reality is that there’s layers of ... security is a defense in depth strategy and it’s the same in the cloud that it has been traditional on-prem. You have to think about how do I put the controls in place, but then how do I also empower end users to make smarter security decisions and give them the visibility that they need to take control of their security experiences.

Another feature that we recently launched in BETA, that I’m also very excited about, is credential reset in the moment notifications. On the MFA side, if a user enrols in a new MFA factor, or if a MFA factor is reset, the end user gets a notification and this, again, just giving visibility to the end user that a change in their profile has taken place that might affect their security posture and if that looks out of the ordinary, for whatever particular reason, they can be enabled to contact the IT help desk and help them figure out if that is a security issue.

With that, I want to say thank you. That’s our security talk for the day. We’ve got about four minutes for Q&A if folks have any questions.

We’ve got a question in the back there.

Alex Bovee: Yeah. So the question was around password reset. That’s tied up in secure enrollment and recovery. I didn’t touch on it at that level of depth, but, basically, we are rationalising our recovery experiences with our enrollment experiences, making sure that you can use those same set of factors for proofing yourself before enrollment, as well as proofing yourself for recovery, whether that’s account recovery or password recovery. The idea is, at the end of the day, a password is just another type of credential. It’s not a special credential. As we think about moving the password-less experiences, the question becomes how do we strongly identity proof this user to make sure they enrol, how do we identity proof this user to allow them to rest or recovery their factors? Those are two different policy frameworks and the way that you can drive those experiences and identify the users through the mix of the contextual features that I talked about, the authentication capabilities that we support, so all of our different authenticators, or a custom authentication experience if you want to home roll your own identity proofing experience or integrate with a third party for identity proofing.

Speaker 2: Will you ever get to the point where you’re using Windows 10 be able to have...

Alex Bovee: Yeah. Absolutely. In fact, we support Windows Hello integration today for a step up authentication so you can use Okta ... You can use facial recognition for step up authentication.

Speaker 2: I don’t mean for Surface Pro, I mean for regular computers. 

Speaker 2: I have a microphone, whoa, I have microphone now. Anyway, is there a way to look at using Windows 10 to have Okta sit in front of Windows 10 to use second factor authentication without using Windows Hello?

Sami Laine: So logging into Windows 10 you mean?

Speaker 2: Yeah.

Alex Bovee: Not today. I’d be happy to take it offline with you and explore the use case afterwards. I think, Windows 10 solves some interesting problems, just strongly authenticating the user to the device, it’d be interesting to take that offline.

Great. Any other questions? Yeah.

Speaker 3: Do you guys have any plan-

Sami Laine: Microphone coming.

Alex Bovee: Yeah.

Speaker 3: Thank you. Do you guys have any plans to let administrators view what’s in the user behavior? What’s being stored?

Alex Bovee: You know, we’ve talked about it. I’d be happy to explore that use case with you as well, offline. Where it’s primarily come up is around things like devices, so I know that there is a strong desire to expose the list of devices that are associate with a user’s profile, and, frankly, from an end user security perspective, I’m also excited about that. Just allowing end users, when they log into the Okta portal, to see the devices associated with their account and revoke OAuth tokens and things like that from those devices.

That’s definitely something we’ve talked about. Outside of devices, I’m not sure if you have a use case there but I’d be happy to explore that with you afterwards.

Sami Laine: Today, the administrator can reset that behaviour if they so need to.

Alex Bovee: Right.

Sami Laine: You had one more. Time for one more question.

Speaker 3: Do you have anything for integrating in with third party products to take feeds from devices reputation and stuff?

Alex Bovee: Yeah.  Yeah it kind of depends on how you want to do it. Our fingerprinting solution is actually abstracted at the API level, so if you want to bring your own fingerprinting technology, you can actually do that with Okta today. That’s exposed in our developer website. I think you might be asking a slightly different question though, which is how do you call out to maybe third party, sort of, device to station services to do some sort of integration there. There’s two different patterns and approaches for that. One way you could look at doing it is with the custom factor experience. At the end of the day, that doesn’t necessarily imply some sort of a user interaction, so you could redirect that user to that experience, maybe check whether the endpoint software is on that device and then redirect the user successfully authenticated in that experiences. It’s a way, sort of a test, that the security posture of the device separately if your use case is more around ... I want to just pull in signals from a third party device feed and use that for step up auth. That’s a little bit more in extensibility capability we’ve been building out from a platform perspective and, I think, there’s a session on that in Okta, although I’m not 100% sure what it is. Key word is extensibility.

Alright, I think we’re out of time but happy to take some question afterwards if folks are interested. Thanks everyone.

Sami Laine: Thank you.