Oktane18: Roadmap -- Building the Future of Access Management

Speaker 1: Hey, guys. Thanks for coming by today. I hope Okta's ... Or Oktane, rather. Has been going well for you. I'm glad you were able to find this room all the way back in the corner here. It's kind of cool to see Oktane actually grow so much, this is the third Oktane for me and it's totally changed over the past few years. It's great to see so many people coming out. Today, I'm here to talk with all of you about the future of access management at Okta. My role at Okta as director of products within our access management space includes a bunch of different functionality around authentication, federations, SSO, API, access management, and end user experience. As well as, identity providers that you connect into Okta.  We'll walk through all of that today and I'll give you an idea of some things that we've released recently, as well as what's coming down the pipe. And then, we'll have a few minutes for Q&A at the end and you guys can ask many any questions you want. Whether it's super detailed or something more generic about what we're working on.  John already called out the disclaimer, I'm going to be talking a lot about things that we're thinking about building over the next year. Plans can change, priorities can shift. Hopefully, it will deliver all of this, but don't make any serious decisions based on something that we haven't delivered yet. To start out, I want to give you a bit of a picture about what we mean when we refer to access management. It's really more than just authentication protocols that a user might go through. Okta started out all about connecting users to applications and over time, that flow has gotten more complex and we've added more details into the access management decisions that we make. We can take into account different protocols or credentials and metadata about a user as they're trying to access something like the device they're using, they're using, their location, or the network that they're on and feed all of that into our access intelligence engine to determine if a user should have access to an application. But, overtime it’s become more than just users in Okta. It'll be additional identity providers that maybe you're connecting to Okta. Maybe it's third party SAML IDPs, it could be a social authentication provider. In the future, it might be a number of other types of providers. It's not always just applications that you're accessing, it could be networks or APIs. Maybe you're trying to protect certain resources and building authorisation policies around those APIs. 

This end to end flow that's kind of evolved over the past few years has gone from something pretty straightforward, to a much more interconnected web of different identities and users connecting to many different things beyond just applications. As I step through this flow, I kind of think about it in a few distinct sections.  The first is, pre-auth. If you're looking really closely you'll notice I don't authenticate in, or AUTH Z. Intentionally, generic there. But, pre-AUTH is basically where a user might be coming from and where that user's identity is stored. Then, you have the authentication section. This is authenticating the user, validating that, that identity that the user is claiming to be is actually their identity.  Then you have post-AUTH, which is what the user is eventually accessing. Whether that's an API endpoint or and application. Overarching, all of this is going to be about the end user experience. The user's going to be clicking through UIs, entering their password perhaps or other things going from that journey from indicating where their identity is stored, into accessing the application or resource that they want to access. Today, we'll walk through these four different sections and I'll tell you a little bit more about what we've released recently and what's coming up. Throughout all of this functionality and all of this discussion, you'll see three themes that keep popping up. It's going to be customisation, security, and extensibility.  Our focus over the next year is really going to be delivering more capabilities for you to customise user's experiences in their access management journey, making sure it's a secure experience. Then, also allowing you to extend Okta's functionality to leverage investments that you may have made outside of Okta to help enrich that access management experience. We'll start out talking about our user experience. A few taglines from members who talk about this, we're trying to customise all the things, bring a delightful experience for users, and break that experience down into modular components so you can compose the workflows that you need to deliver the identity in your access management experience for your specific use cases. 

The vision for our end user experience includes building a first class, secure, and delightful tool that eliminates obstacles in our users access workflows. That includes, security, user centred experience, reliability, and frictionless. When we say frictionless, this basically means that it's as smooth as possible for users.  A lot of times you can find that security and usability end up at opposite ends of the spectrum, but as we're building new functionality we're looking at how can we get improvements in both security and usability? The user journey that we talk about when I refer to end user experiences starts out with the emails. This might be your, "Welcome to Okta." email. It's the initial onboarding notification that you'll get that a user account has been created. Once you click that email, you may be taken into a registration or an onboarding flow to setup your password, and then maybe an introductory tutorial the first time you log in to Okta.  If you're using a platform use case or an API use case, maybe they're not ending up on the dashboard, but they're going into some application and having a tutorial flow there. Of course, after that initial onboarding, you'll have you're authentication sign in flow, which include entering your username and password, our nice little spinner for when you're waiting for the redirects to happen and you actually get logged into an application, and then any error experiences if you end up on a page that doesn't exist or something like that. Then, we have the flow that when you actually get into either Okta's end user application, which is an example here where you see what we call our trickled dashboard or the app request dashboard on the right. Or, any other flows that you might be entering into if you have custom applications.  Lastly, there's user settings. Users may come back and need to change their password, update their name, or something like that. We have a built-in page for that today. When I refer to end user experience, these are the different components that we're talking about.

Let's talk about what we've released recently. We've made some huge strides over the past few months to make the end user experience much more customisable for our customers and different organisations leveraging Okta. One of the first launches has been custom URL domains. That means that no longer do you need to navigate to "org.Okta.com", you can actually run Okta on your own domain. You can have "login.YourOrganization.com" or something like that. This is really critical for a lot of scenarios where you don't want either your employees or your customers to really think about interacting with some third party called Okta that they may have never heard of.  Instead, they can go to a URL they're familiar with, maybe it's the name of your company, and then they can feel that the experience they're having and the identity that they're providing is a part of your organisation. The experience that you're building. What's tightly coupled with that is what we're calling Okta hosted custom HTML. I know that's a bit of a mouthful, but what it basically means is that you're able to customise the HTML and the JavaScript that's served on the login page for Okta, but it's all hosted by us. That way, you don't have to deal with figuring out how to deploy a custom version of our widget on your own infrastructure. Instead, Okta's still managing the entire authentication flow, but you have complete control over what that looks like and how it behaves. There's also our recent EA with self-service registration. We can finally sign up users with Okta and they can sign themselves up on their own. You don't have to build an entirely custom workflow in order to achieve that. All three of these features, we released in EA the other week and you can go and try them out yourselves. Play with them on the developer orgs or you can email your CSM to have it enabled in your production org today. Another customisation feature that we've had for a little while and is now moving into GA is custom email domains and templates. 

This follows the same concept as the custom URL domains where the email that you would get when you first sign up for Okta would normally come from "[email protected]", which is kind of a crappy email to get, because you don't know what to do if you have an issue. With custom URL domains ... Custom email domains. Sorry. You're able to send that email from an email address of your organisation. That way people know who they can respond to if they needed to ask for additional help, and also they feel like it's a more connected experience as you link all of these customisations together. Alongside that, we also have fully customisable email templates. If you need to send out emails in different languages, you can customise the onboarding emails, password reset emails, and other interactions with the identity flows, all within Okta using custom template for ever language that we support. Another feature that we launched that is more targeted at those users of our end user dashboard is what we call, admin managed tabs. That enables you to bootstrap a list of tabs showing the applications that you can SSO into as a part of your Okta dashboard. You can configure that on the admin side, and then provision that in to individual users. That way, the first time somebody logs in to Okta they're able to see a better organisation of the applications they may interact with. We've also, along those lines added admin managed notes or admin app notes where you can add a note for your end users about an application on the trickled. Perhaps, there'll be a new application that shows up and they might not know why that app is there. 

With admin app notes you're able to indicate to those users, "Hey. This app is for your HR paperwork, you can open it up to configure your direct payments." Or something like that. You can also provide information like an email address that they could contact if they have any issues accessing the app or using it. All these features have come out recently, they're in EA or GA, and those feature life cycles for us mean that you can use them in production. Super excited to see what people do with all of these and I'm really glad that we made all these strides in customisation and personalisation for your Okta experiences. I'm going to show you a little bit about what these features actually look like in action. First example is going to be our Okta hosted custom sign in page. This is, on the left what you see normally when you go into an Okta org. You just get your username, password entry, quick sign in. It's blue, it's got our branding. Yay. That's not great if you don't want to look like Okta. With custom hosted pages you can do anything you want. If you wanted to have a giant storm trooper face, and a user selector, and a bright yellow call to action you could do that. You can do this all right within our admin UI. You could just drop in your customised HTML and Javascripts right in the admin UI and we'll serve it up for you on your login page. 

Similarly, for our error pages you may want to have some customised experiences for those delivering specific messaging to your users if they end up on a 404 page or something like that. Or, just removing the Okta branding. That again, let's you deliver that seamless experience for your users. Following our same Star Wars theme, if you wanted to change your 404 page to show something like this it would be right in the admin UI. Drop in your customised HTML and we'll serve that up for you again for anytime a user ends up on an error page.  Now, let's talk about roadmap. This is the stuff that we're working on today that you'll be seeing come out over the next few months, up to the year. One, is a redesign of the end user experience. We're leveraging a lot of data about how users interact with the Okta dashboard to figure out what we can do to deliver better value for those users. It's kind of unusual for me as a PM to think about building a product where the goal is to get people off of that product as quickly as possible. Really, you don't want to sit on an SSO Dashboard all day long, instead you're trying to get into the applications you care about.  We're looking at how we can surface relevant information or relevant applications for users that they interact with frequently in order for them to more quickly access the applications or resources that they're interested in. We'll be looking at different pieces of that, that we can bring into the experience into the next year. We also want to enable more and more unique and customised access flows. What you see on this screen right now is the different segments I mentioned about the user experience and highlighted in blue are the two that you have full customisation control of today. But, over the next year we'll be looking at ... As my PM Jade, sitting in front me likes to say. Widget zing all the things. 

It's basically taking those other components of the end user experience, and breaking those up, and making them customisable in the same way you can with a sign in widget today. That may be separate modules or it may be wrapped into the same widget, but the idea will be to deliver you the same customisation that you can do on sign in with the other components of the end user experience. Lastly, we're thinking more and more about encouraging secure behaviour for end users. Surfacing information to help end users behave in a secure way, through indicating login attempts to their account so they might be able to see if their account may have been compromised, showing them what MFA factors they've set up or other information that might help them act in more secure ways. Because, ultimately if you put the power in the hands of your end users to act securely that will help increase the security of you organisation. That's the end of our end user experience section. Now, we'll talk about the pre-auth section. This includes IDP discovery and routing, generic open ID connect, and social authentication. We'll start out with IDP discovery and routing, this is a feature that is now available in early access and we've seen really rapid adoption across a number of different use cases. IDP discovery is important for those organisations that have more complex identity ecosystems that need to connect multiple identity providers to their base Okta organisation. Over the years, most organisations have needed to engage with our professional services group to build out these custom flows when they need to connect additional SAML IDPs or other things like that to their Okta org. With IDP discovery and routing, we built a completely custom policy layer that can direct users to the right IDP based on a number of different conditions so that they can authenticate ...

Speaker 1: BP based on a number of different conditions so that they can authenticate at the correct identity provider and then be federated back into the Okta organisation. So this removes a lot of the custom code that customers have needed to build in the past and gives you a very flexible and easy to configure a policy engine on the east side. So let me take you through what that policy rule actually looks like. The conditions that you can control today are what network the user is coming from, what device they may be on. So, if you want to direct all of your mobile users to workspace one, for instance, you can set up a rule that says anybody on a mobile device send them to the workspace one IDP as a SAML IDP that's connected to your Okta organisation. You can also specify for specific applications. So if you need to use a certain IDP for users that are accessing a Salesforce application, you can specify that right in here, either at the application or the APP instance level. 

And then we can do that routing. The last condition here is the most flexible, which is a user matching condition, and you can basically define a condition for a red x on a username or any attribute associated with a user, in order to flexibly send those users to different IDPs based on information about them. And when you've configured the user matching rule, what the end user will see is an identifier first flow, where the first page that they get instead of a username and password, will actually just be a username entry. And then we'll route them to the appropriate IDP based on that information. So this is available today, and you can set up and use it in your organisation.  Looking forward to what's coming next. It's adding more IDPs to your Okta organisation. We're going to be adding generic, open ID connect identity provider support within the Okta orgs. So today you can connect social Okta providers like Facebook, Google, Microsoft, and you can also connect Saml IDPs, or IWA. But what you can't do yet is open id connect IDPs. And so, we're going to be opening that as a generic connector for you to bring in those identities from any YDC IDP, whether it's something like Yahoo or could be an enterprise IDP that's been built that you want to connect into your Okta organisation. Going beyond that, we're looking at bringing our social authentication experiences into GA, which will include improved profile syncing and advanced linking policies for users that are coming in through social authentication, the IDC support I mentioned. And then also we're looking at how to more flexibly support O-Auth two identity providers. And so, for those of you that are more familiar with those two protocols, you'll know that open id connect is built on top of O-Auth Two. But the reality is that there are a number of identity providers that built identity into O-Auth Two independently of the OIDC Spec. And so, in some cases we've had customers that need to support those IDPs and we're looking at how to do that more scalable within the Okta organisations. 

Now, our authentication pipeline. A couple really exciting things here. And to start out, let me tell you a bit about what the authentication pipeline looks like at Okta. The first step is going to be the IDP discovery that I discovered, or described, determining where a user will actually need to authenticate, either with Okta or with a third party identity provider. If you're authenticating with Okta, you'll go through your primary authentication flow, entering a username and password, and then potentially going through your new user enrollment if you haven't done that yet, or setting up credential recovery or going through that if you've forgotten your password. As soon as the primary author is completed, you'll be directed to multi-factor authentication if it's configured. And you can enforce that multi-factor authentication, whether a user's coming from a third party IDP or they're coming from an Okta IDP. Once the user's identity has been established, we can apply APP sign on policies if the user is trying to log in to a specific application. So this is the basic authentication pipeline within Okta. And the enhancements that we're looking to make over the next year include finally making an API for app sign on policies, so that you can more scalable configure policies for the individual applications that users may be logging into. And then also extensibility. This is probably a concept that you've heard a lot of people talk about in different sessions today. And for the authentication pipeline, when we talk about extensibility, what we're referring to is adding specific hooks at different transition points within the authentication pipeline where you can take additional actions or make access decisions outside of Okta. So it might be that after primary authentication, you want to do some additional identity proofing or context collection about a user, or even, after a user's authenticated, ensure that they accept some sort of a terms of service before they're allowed to access the application. As we're going into more and more scenarios where people are concerned about privacy policies and terms of service, being able to enforce this as a component of the authentication pipeline is becoming more critical for many of our users. Uh, whoops. I skipped forward. So that's kind of our vision for the extensibility and the API's that we're going to be building into our authentication pipeline over the next few months. Let's talk a little more near term about recent releases. Available now is our PIV card authentication experience. So, for particular users in the federal space, PIV cards are commonly used as a way of asserting a user's identity. And we have that available in early access today and we'll be looking at moving that into GA over the next few months by adding some additional support. We've also made security questions an optional component of your user enrollment flow, so that you can exclude security questions if that doesn't make sense for your specific use case. 

The PIV card, or more generically smart card GA, is basically assert based authentication. And so we're looking at how the enhancements that we can make to make this a more general support for users outside of just the federal space. And one of the key components of that is going to be multiple CERT chain support. For anybody familiar with this already, you may need to include multiple CERT change within your PIV IDP in order to log in all the different users from all the various PIV cards that may have been issued to those users. And longer term, we're looking at the call outs and web hooks and the authentication flow that I highlighted on the previous slide as well as the APP sign on Policy API. 

So, I'll show you a little bit about what the PIV card experience actually looks like. You'll have a similar landing page when you go to your Okta organisation, and you'll be able to click a button that says, "I want to sign in with PIV card." And that'll actually prompt you, within your operating system, to enter a pin for the PIV card, what you would need to connect to your computer. Then that card would release a certificate which proves your identity and then it would log you into the system. So, the cool things about PIV card is that cert-based authentication, and it requires identity proofing before issuance. It's a really strong credential, because to get that PIV card, you need to go through an additional process in order to be issued that card. And then that's strongly tied to your identity, a set of cryptographic keys that are protected by a pin so they can't be  ... or it's harder to phish them. And then it also provides that identity proofing. What's really interesting about PIV card is it's kind of the first step in a password less experience where users no longer necessarily need to enter passwords when they log into Okta. I saw some of this demo today in Todd's keynote, and password less for us means stronger credentials and rich context and the ability to improve both user experience and security, because you're removing that need to remember a password alongside being able to use much stronger credentials for user authentication. So, let's see what a password less experience would actually look like. You go to your sign in page, you'd enter your user id, click sign in, and then that would trigger an Okta verify push notification where you could simply click approve, and then you'd be granted access in that initial device that you were using. No password needed, really seamless, and it gives you a much better user experience and faster access to your applications. 

As far as configuring password less, when we refer to this, it doesn't actually mean that you have to get rid of passwords. You may have certain users that you're always going to want to have tied to passwords. And so, for us, a password less experience is actually more like what might be called credential chaining, where you can set up a series of credentials that you need to authenticate a user's identity, and then have different policies or rules associated with that so that you can have customised experiences based on the user types that might be authenticating in different ways. So we know that it might be a long path to getting rid of passwords. But by giving you this chaining experience, you can kind of transition from the old world to the new. Now speaking about user experience, there was one other big announcement that Todd made earlier today which is sign in with Okta. And this is a feature that we've been working on and are showing us a demo right now. And it's going to be a roadmap for us. It's going to take a little while to get right and get released. But sign in with Okta is very similar to what you may have seen with sign in with Google or sign in with Facebook. It's a way to federate a credential into an application without needing that application to have any username or password, similar to what you can do with SAML today. But the reality is SAML was kind of hard to set up. If you look at OIN, 80 percent of apps in the OIN don't support SAML. And one of the reasons is that it takes a while to configure that. 

You have to determine per-org trust and set up individual integrations for these SAML experiences, which many smaller ISVs or SAS App developers aren't able to do. Sign in with Okta makes that significantly easier, so just like sign in with Facebook, sign with Google, sign in with Okta is based on open id connect. And all you need to do is point your open id connect requests at a global app that we're building called login.okta.com, and then that application is able to speak with individual Okta orgs based on an accounts user and log a user in through that organisation, and then federate back into your application. So you don't need to maintain any sort of client side logic about, "Hey, this user's email domain means that they're using Okta versus Microsoft versus something else." Instead the user can just tell you upfront, "Hey, I want to sign with Okta." Click on sign in with Okta, go to an accounts user experience to direct their open id connect requests to the appropriate organisation. If they already have a session, they just log straight back into the application. No need to log in again, no additional credentials. What's really neat is that you can apply this for org to org scenarios as well. I'm sure some of you in this room have had to set up SAML organisation to org trust between two Okta orgs and federate users between the two. And you can do it, but it takes a while and it can be kind of confusing. And it can really be tedious if you have to keep adding more and more organisations. Sign with Okta will be a feature that you can use with org to org as well, where you can configure specific orgs that are allowed to federate into your primary org with sign in with Okta. And so this experience would be quite similar. If you're building a B2B portal, you might have your Okta login page like we have right here. You click sign in with Okta, and it may take you directly into that portal based on an org that you had selected. You still see that accounts user again, but it would be that simplified flow, and make it easier on the Okta admin to configure these trusts as well as the portal developer to set up that button just to talk to the main login, that okta.com global application.

So, sign in with Okta is easier for developers and IT admins to enable the most secure user friendly SSO for all of their applications and organisations. Now talk about post auth and I'm going to focus on one specific feature or product that we have when I talk about post authentication, and that's API access management. So for those of you in the room that aren't familiar with API access management, I'll give a quick overview of what this product actually does. Let's imagine you're a solar retailer. You build a bunch of solar panels, you install them on different homes, and then those homes over time are going to be generating electricity through the solar panel and either consuming them at the home or putting them back into the electricity grid. You may have a set of APIs that you've built to expose certain information that you have, maybe it's some CRM or profile information, as well as some usage data about what those solar panels are generating. You may be developing some custom applications that leverage those APIs. So you might have a customer lead application, so B2E app, so it's something that you're deploying to your salespeople who are going door to door to try to sell more solar panels. They may need to access a profile database or some other CRM database to provide information about the account that they might be trying to set up with a new home. In many cases, these apps may be set up without any sort of security around those API requests. Maybe you put an API token directly in the APP or maybe you don't have any authentication at all. API access management allows you to configure an authorisation engine that will take into account a user, the groups that they're in, the application that they're using as context in order to make an access determination about what that APP would be able to access with your APIs.

So the application would talk to Okta to get an access token or identity token, and then it can use that access token to interact with your own custom APIs. And this is all built on top of O-Auth Two, so we kind of call this O-Auth Two as a service sometimes. But this unlocks a bunch of other use cases as well. You could start building B2C apps, so an application for the consumers that actually have the solar panels installed on their home. That application might be a mobile app that talks to both your usage APIs and your CRM or profile APIs and that can use the same authorisation policies in order to get those tokens to interact with the APIs. But it goes even further than that where when you're building APIs, eventually you should be thinking about how you're going to externalise those to folks outside of your organisation. API access management helps you do that as well.

Speaker 1: API Access Management helps you do that as well. You can build third-party applications, so maybe an electric utility would want to access that solar usage information. And that application could go through the same experience with Okta as an authorisation engine. In fact, you could even require user consent for that application to be able to access those APIs. And I'll show you and example of what that user consent looks like in just a moment. With API Access Management, you can build applications that are a component of the API economy and provide flexible and secure experiences for those API authorisations using API Access Management. So that's what the product is, and over the past year it's been pretty exciting. First we've launched user consent, which is a huge component and something really important, as you're looking at both GDPR as well as providing true information to your users about how applications are going to be accessing their information and their private data. See major customers go live, and I'll also talk through a couple of the customers that we've worked with on API Access Management that have had pretty exciting and successful use cases. And API Access Management is in general availability, so now it's available as long as you're purchasing the scale.

This is OAuth User Consent. So the example before where I was describing a solar panel manufacturer, maybe they're called SunTown. And PG&E might be building an application that wants to interact with the SunTown APIs. So on the right would be a consent prompt that would be shown to an end-user who wants to connect their PG&E application to the SunTown APIs in order to surface solar panel information, billing, and things like that. It gives users control over their privacy and security and the information that they need to make informed decisions about what applications are accessing their private information.So let's talk about what a few customers are actually doing with API Access Management. One of the first examples I want to describe is Dignity Health. So they're a public company that provides network-enabled services for healthcare. And they built a patient portal, and that portal can talk with a number of different API endpoints that they have in the back end that can provide information about their healthcare, upcoming appointments, data about ... maybe suggestions for medical care and things like that or prescriptions. So API AM provides the ability for them to consolidate all of those applications and endpoints into a single portal and then have a unified authorisation policy so that they know what those applications are able to do and what different users are able to access, based on the groups that those users are members of. Another example is a car dealership platform that we've been working with. So this is basically a large organisation that has over 170 internally developed applications or applications of companies that they've acquired and rolled into their portfolio. This platform offers a number of different services including things like service scheduling, or looking up recalls on certain cars, or other data about what you need to run a car dealership. They're using API Access Management for both customer and third-party partner access to applications and data. So they can use a user consent for those third-party applications to come in and access that data that's exposed within those applications. Or, for their internally developed applications, they can provide exactly the access policies that they want to configure for how those applications need to access information.

But it doesn't always need to be external users when we're talking about API Access Management. We also have a lot of customers who are building just beta e-applications, just apps for their employees that leverage API Access Management. So for a leading media organisation, they have an internal benefits portal for both current and former employees. And that portal includes some pretty exciting benefits, including access to streaming media content. So as a former employee of this media organisation, you can come back in and access streaming media that normally you'd have to have a subscription for, but because you're an alumni, you're able to access it. And they actually have configured their access policies within Okta, using API Access Management to control how those streaming applications are able to access that media. So all these are examples of really diverse customers and use cases that have been deployed on top of API AM. But there's a whole lot more coming. So, laid out here is basically how API AM works today. You got some internal applications and some third-party applications on the left. You've got Okta as an authorisation engine. And then for a lot of large organisations, they're using our API Access Management product alongside an API gateway. That could be Apigee, MuleSoft, AWS API Gateway, Kong ... there are a whole host of them out there. And that API gateway works hand-in-hand with Okta to deliver the full API economy experience that you might want to build as you're exposing your APIs both internally and externally. And these two components together enable access to your API resources. 

So what are the next things that we're going to be building? One is going to be allowing you to better leverage developer ecosystems through more fine-grain control of what applications are able to do. And also allow you to more scalable configure those applications. So for example, today you need to configure access for individual applications as they are created, and then add them to an access policy, and then they can have the behaviours defined in that policy. But if you're adding thousands of applications, that can take a little while. We do have a full set of APIs for managing this, but we also may have users that would like to configure at the time of creation for an application the scopes that it might have access to. And so it would automatically have that access policy kind of written into the metadata about the client. So that's one of the examples of something that we're looking at adding. So as users have more scalable ecosystems that they want to support, and larger ecosystems, they're able to do that with Okta. The other thing we're doing is investing heavily in integrations with API gateways. So we already support Apigee and MuleSoft and we're working with other gateways in order to have more first-class integrations, so that the clients that you may create in Okta are synchronised with the clients that are set up in the gateway, so that you can use these two as complimentary tools. There's also extensibility. We've seen many, many examples of customers who are storing some data outside of Okta that they want to include in the access and identity tokens that are generated for API Access Management. A great example might be that you're building a medical application that a doctor uses to view electronic health records. And you might want to get information about patient IDs for that access token to be used as it's interacting with an electronic health records API. But you might not want to store those patient IDs in Okta. You just want to store the doctor's identity in Okta and then associate that with something outside. So with extensibility you could call out to some external service, get those patient's IDs, and we'll mint them into the access token that is then passed to the API resource. So it lets you more flexibly utilise API Access Management alongside the custom-use cases you might have. And with all this growth around API Access Management and microservices and other use cases, we've seen that more and more often folks are really interested in understanding how many tokens are being minted, how are those access tokens being used. And so we're going to be building out token reporting dashboards so that you can get an end-to-end view of how tokens are being used across your organisation and your deployments.

We're also looking at leveraging extensions to the OpenID Connect specification with the OpenID working group around financial and health care APIs. And the reason that we're really focusing on these additional vertical-specific extensions is that they're running into a lot of the problems or a lot of the questions that we expect others to run into in the future. Thinking about how do you manage things like highly sensitive information, how do you allow people to request the right to be forgotten. And other data like that or other use cases like that, they're ultimately going to benefit every user of API Access Management. But there are focused working groups working through these problems today, and we're tracking those developments closely, and we'll look at building enhancements into the API AM product to support those vertical-specific use cases. And lastly we're going to continue investing further in encryption and security, and that's going to include things like encrypted jots, or token binding, or new client authentication methods that will allow you to use API Access Management for higher-security use cases. So that's just kind of an overview of some of the major investments we're going to be making in our post-authentication experience in the next year.  There's one more thing we want to talk about. And that's API keys at Okta. I'm sure many of you have set up API tokens and they're very, very coarsely-grained permissions, I'll say, to be generous about it. You don't have the ability to really craft an API token for exactly the use case and you end up giving these API tokens out that may be over-provision for what you really want them to do. So one thing that we're really actively working on is finely-scoped authorisations for active APIs using OAuth 2.0. I'm super excited about this. We'll be reaching out to customers for participation in early betas of this very soon, and this will finally give customers the full flexibility that they want to set up either management or admin experiences outside of Okta with tightly-controlled tokens and scopes. And with that, we have about six minutes left for Q&A, so if anybody has any questions, I think we have John  [crosstalk 00:38:02] around with the mic.

John: A roving mic, so raise your hand if you have a question, I'll run to you. Question right in the front.

Speaker 2:Thanks. Based on the html pages and road map you were talking about for other end-user experiences, are we going to be able to add on JavaScripts for, let's say, IT managers with chat? So chat widgets adding onto perhaps the dashboard or the settings page or whatever?

Speaker 1: Yeah, so the custom html that we've released right now is just for the sign-in page, but you can add custom JavaScript there, so if you wanted to have a "contact the help desk" or something like that on the sign-in page, you could do that with the functionality that we've released already. So it's full control of the html and if you want to run custom JavaScript there. Prerequisite of running that custom html and JavaScript is that it is running on a non-Okta URL. So you have to use the custom org URLs feature alongside it, but that also enables you to run or execute arbitrary JavaScript. Longer term, as we build out those other modular components, the goal is that we give you full customisation in the same way. So that would be the end state, the best road map for us right now.

Speaker 3: Are you investigating the use of the new WebAuth standard for doing either primary or secondary auth in Okta? 

Speaker 1: Yeah, we've definitely been looking at WebAuth and Standard, and we're going to look at how that evolves. I think, looking at ... browsers are starting to adopt Web AUTH more, and as they adopt them we're looking at supporting that more fully within Okta.

Speaker 4: Okay, cool. This is really low-tech. Time zone awareness for your UX. Onboarding, pre-start interval, terminations ... they're all critical to happen at the right time, and there doesn't seem to be any time zone awareness in Okta. And we actually had it custom-built in for the pre-start interval, and it wasn't that hard. Is there anything we can do about that?

Speaker 1: Maybe we should sync up offline. Maybe I can get a little more details about what you're trying to accomplish. I don't have anything specific off the top of my head, but I think with the customisation features we're releasing, we should be able to connect that in with some of the experiences to probably give a better experience.

John: Anybody else? Alright, well thanks again for the session.

Speaker 1: Great. Thanks guys.