Okta Today and Tomorrow: Going Beyond Internal Access Management

Speaker 1:  I'd like to introduce John Gronberg and Marc Jordan. John is the Group Product Manager at Okta and Mark is the Senior Product Manager. And John will get us started. Thanks John. 

John Gronberg:  Hi guys, how's it going? Thank you for joining our roadmap session. This is, as it says up there, Okta Today and Tomorrow, Going Beyond Internal Access Management. So this is our roadmap presentation to walk you through what we've been working, within our access management products. And Marc's up here with me as well, he's our PM for directories. I'll take you through a bit of an intro then he'll hop in, talk about directories. And I'll talk to you again for another 30 minutes after that. 

We got a lot to get through today, so apologies if we're moving a little quickly. But there's a lot of cool stuff that we have been working on and we'll be working on. So I wanna make sure to tell you all about it today. So, before we get started I have a little eye test for you, here's our forward looking statement covering all the things ... we're talking about a lot of stuff that we haven't built yet that's currently on the roadmap. We're thinking about building it. These are the priorities today, but, as you all know business priority and requirements can change. So, some of these things may not be delivered on the timelines we talk about today. But I wanna give you guys the most full disclosure of the things that we're prioritizing. So we'll walk through those accordingly. And without further ado this will be modern access management. 

So to get ... to set some context on what we're talking about I'll tell you a bit of a story about where Okta started and where we're going today. So, when Okta began we were all about connecting employees to applications. Basically single location to sign in and get your single sign on dashboard to log into a bunch of different apps. But over time those requirements have changed. It's no longer just employees, it's partners who may be outside of your organization who need to connect to those applications. It could even be customers, people who don't have ... don't work for you, don't have a contract with you or anything like that. And the way that people access those applications has evolved as well. It's not as simple as a username and password, it's taking into account context and behaviors and policies configured within Okta to determine how people can access those applications. 

So, things like the protocol that the application uses, whether that's SAML or Open ID Connect. Or the credentials those users have, password list or a basic password. The device you're on, whether they're using a mobile device some connected device of another sort or a desktop computer. Location therein, and also the network they're on, whether they're within the VPN or outside the network. And where those users come from has also changed. It's no longer just users stored in Okta's universal directory, it's users that might come from additional identity providers majorly social auth providers like Google or Facebook. 

Or also additional directories like AD or Ald App as Marc's gonna talk about in a moment. And it's not always applications that users are connecting to either. It might be additional networks or a product that I'll talk about at the end, APIs with API access management. So as you can see over time things have evolved quite a bit from just connecting employees to applications. It's become an entire access intelligence engine where we can take that context and behaviors and apply policy to determine what people are allowed to access and how. 

So, what I'm gonna walk through today is going to be four different sections of the products and investments that we've been making. Starting out with Marc talking about directories and integrations particularly active directory and Ald app. And I'll come back on stage and talk about Identity Anywhere, and that's our social authentication and our core SSO products. And then the customizable user experience. You saw some of this in the keynote demo that Hassan and Eric delivered with Todd, but I'll dive in a little more about what we're doing to ensure that you can completely white label your experience with Okta. And then lastly I'll dive into my favorite product which is API Access Management and talk about how we're helping you secure your interactions within the API economy. So to start out I'll hand this to Mark and he'll talk about directories and integrations. 

Marc Jordan:  Great, thanks John. As John said, I'm the Product Manager for our directories and our integrations products at Okta. And so I'm gonna take you through some of the key tenets that we think about when we think through how to integrate with directories and beyond. And so, we've got a couple of goals. You know this is a roadmap session. And I wanna talk through where we're going directionally and what we're thinking about. Key to that is we know you've got AD and ... probably got AD in house today, you've probably got an LDAP server. But you've probably got Oracle databases, you've probably got SAN, you've got all sorts of Postgres and all sorts of stuff that sits in your environment that's storing user information. Whether it's your consumers or your customers, it might be your partners or something like that. We wanna make sure that we can connect to any directory regardless of what it is. So we'll talk a little bit about that today. 

I also wanna talk to you about Cloud First Architecture. I see a lot of people in this room who are moving to the cloud, on this journey to move infrastructure, to move services to the cloud. And in doing so, Okta, we don't want Okta to be the blocker that stops you doing that with on premise agents, on premise infrastructure, all these bits and pieces. And so where possible we wanna move you to the cloud faster. We wanna get rid of these on premise pieces of infrastructure that Okta's developed, that you've deployed in your environment and help you smooth that transition to the cloud. 

Next, it's managing identity, identity across silos. So you might have active directory users, you might have LDAP users, you might have AWS directory users or GCP users. How do you keep everything orchestrated, everything intact? When a change happens in AD, how do you get that change off to your cloud based directories? Or if you've got consumers that exist in your ... in an AD or something like that today, how do you get them from there into an LDAP Directory an internal FAT service? So, these are some of the things that we're thinking about as part of this transformation to the cloud. 

So, first and foremost I wanna take you through some of the recent advances we've made to our AD integration. Now, although the customers or the prospects that I talk to ... they might have one active directory instance or a single AD forest, but there's a lot that have more than that. I've, I've spoken to customers that have several hundred or even 1000 active directory instances, which, for me access management from a life cycle management point of view, that's a struggle. So we made some really, really significant enhancements in our delegated authentication flows, so that you could have users authenticate to the right active directory instance that they should be authenticating to. So, you know you can granually turn off delegated authentication, turn off AD instances for that and just use them as a source of information into Okta. So, we think that's really important to help manage, to help smooth this transition. Whether you're trying to get rid of ADs or trying to collapse forests into another. This change for a delegated authentication is enabling you to just really use these as profile masters, as attributes stores to smooth that change. 

Next is our AD agent. We've been doing a ton of work on this. And we actually have a new early access agent that I'm gonna give a huge plug to, it'll be available next week. I'd love for all of you in this room to go and deploy our new AD agent, get a chance to use that. In this agent we're seeing performance improvements of up to 90% for some of the testing that we've done. So, you know, we see some customers that their AD imports take up to two hours, three hours or more. In some of these cases we're seeing the improvements go down to minutes rather than hours. So we think that's a huge change. We've also significantly improved the logging. So, no more do you have to dig through agent logs on the on premise server that's ... a lot of that's gonna be in your system log. And we're continuing to make improvements there. So, our agents, whilst we're trying to move you to the cloud, are making huge strides for this on premise infrastructure. 

The other is SSO customization. As you heard in the keynote and you'll hear from John, we're adding improvements here so you can have the right look, the right feel when a user signs in both in the cloud and on premises. So, you know, if you want branding to show up on error pages, if you want certain pages to show up with a company logo or a background. We ... our new desktop SSO enhancements, we're adding that functionality. 

Profile mastery is a big one. So again, when you've got multiple identity stores, you wanna control what attributes come from where and which one takes precedence. And so we've added significant improvements across all of our directories to enable you to better match users, to better join users, to include users from different places and have the right attributes stored on your users and universal directory as well as in your instances that you're connecting to. 

And finally push groups. So, our push group technology means ... I'm just gonna create a group in Okta and then push that down to a directory, in this case AD. We've made huge improvements there that'll enable you to join to an existing AD group, take over that group and then start managing it directly from the cloud from workday, from whatever the case may be, to enable you to orchestrate that lifecycle all the way down to your on premise infrastructure. 

So these are some of the improvements we've made over the last nine months on our AD implementation. What I'm gonna do is I'm gonna jump to our Eld App changes as well. So, if you haven't heard, we now fully support Eld App provisioning. So, if I've got AD users I can seamlessly move them through Okta and down to an Eld App integration. If they're stored in a cloud directory today, I can pull them in and then push them down to an Eld App directory. And we can use the power of UD to fully map attributes, to customize schema, to support all sorts of different things, to enable you have a really rich extensible profile in you Eld App directories. 

We also offer full life cycle management. So, if I deactivate a user somewhere, that deactivation's gonna flow all the way to my on premise Eld App directory and I can customize that flow as I see fit to ensure that if a user is deactivated somewhere else they're gonna get deactivated in the Eld App store to provide you with a really heightened level of security. For all the Eld App nerds in the room, we now fully support auxiliary classes which is a big deal. If you wanna geek out with me on this later on, we can talk about it. But we're adding this massive amount of extensibility both from UD and in Eld App to support a huge range of attributes, huge range of schema classes, auxiliary classes and all those sorts of bits and pieces like that. 

Full support for schema, Eld App implementation. So if you've created this really custom attribute inside of your Eld App, we're gonna fully support that as well. So if you've got app specific extensions in an Eld App directory you can flow all that directly into UD and have that extensive profile linked into UD. 

And finally full support for incremental imports. We heard from our customers and as we're increasing our Eld App support I've got 10 million, 100 million users in an Eld App store, I wanna be able to just import the users that I've changed. Now we fully support incremental imports for our Eld App services as well. But as you heard in the keynote, some of these changes to the Eld App agent, you don't want to maintain an Eld App server if you don't need to. There's gonna be a situation for, for large complex deployments where you might need to keep an Eld App server on prem, but otherwise why not just use your Eld App in the cloud. And so our UD now supports, well coming soon, has an Eld App interface to it where I can connect Eld App services on premise directly to my cloud based UD. Meaning I can turn off that Eld App server. 

So, as you heard briefly in the keynote and again, if you wanna chat about this later on we can talk through it. But we're gonna fully support users in groups for read and search and authentication operations. So if I've got an Eld App service that just wants to read my Eld App in the cloud that's gonna work perfectly. If I've got users, if I've got groups that I want to represent, this is gonna be a great fit for you. But if you've got massive, massive Eld App stores with rights requirements and all sorts of things, you might continue to keep your Eld App server on premise. So I'm happy to talk through with anyone as to where this is a good fit. Well we think our Eld App interface is gonna allow a lot of our customers to turn off some of these Eld App servers they've got on prem. 

And so, as I said, this is gonna be out in beta very soon. We're expecting it in the next month or two. 

So, what's next for our integrations? There's a couple of things that I'm really excited to talk through here. For active directory we're looking at headless agent installations. We've spoken to a lot of you and you said, "You know we're deploying an AWS, we've got dev ops happening in a big way and we throw away servers once a month, we spin them back up again, and our agent installations are a bit of a friction-ful process and having to type credentials and that sort of thing." As well a system of our large customers, deploying and updating AD agents is a real, real drag when you have to type in a username and password every time. So we're doing work to improve our agent installation experience so you can just deploy an agent, deploy the configuration, it spins up, it knows what's ... what to do and it just keeps working. So that's one improvement we're making. 

For customers that aren't in that sort of model we wanna make agent updates really seamless. I was going through some reports the other day and so that a couple of our customers have agents deployed from 2012. We don't think that's great. We wanna, we wanna make sure you're getting the best functionality of this new performance functionality and all sorts of things like that. And so we are making strides to make sure that you are always on the most up to date version, you are always using the best and brightest functionality that Okta has to offer. 

And this next one here is, is my favorite feature. This is one that we're working really really hard on at the moment. If anyone wants to put up their hand. Does anyone have the desktop SSO deployed today? Yeah, there's a few there, okay. Who would love to throw those servers away? Yeah, thank you, all right, cool. So what we're doing here is we're looking to get rid of desktop SSO servers on premise for people that want to. So, we'll still offer that functionality but for customers that don't wanna maintain servers and load balances and potentially certificates, we're gonna throw that away and do it all in the cloud for you. So, that's gonna be really really cool and we think that's gonna make a big impact both to our small customers who just don't wanna manage it, and our big customers that have traditionally had to deploy lots and lots of IWA or desktop SSO services on premise.

For Eld App we're implementing password sync, we're implementing group push and we're also looking at a brand new setup experience. And for ... going beyond that, as I said at the start, we wanna connect to every directory. So we're gonna make sure that if you've got users in SQL or MSQL, you've got users in Amazon's cloud directory or GCP, we wanna connect to those too as first class citizens and get everything into your directory and make sure that you can flow those users out to application services and other, other directories you might need to. 

So, we know that users aren't necessarily just in on premise directories, they could be in social, social providers as well as in UD, so I'm gonna hand you back over to John who's gonna talk about Identity Anywhere. 

John Gronberg:  Thanks Marc. I'm back guys, hope you didn't miss me too much. So, this section we'll talk about Identity Anywhere which is our core SSO product to connect you to all your web and mobile applications. It's also how we're leveraging modern authentication protocols and enabling those within the product. And then we'll also walk through how you can connect to any identity provider, whether it's a social auth, a generic open ID auth provider or another SAML IDP. 

So this slide should look somewhat familiar, like the diagram I presented at the start. But it's a simplified version, to focus on two components. So one is the applications. Applications aren't just Apps they can be using different protocols like open ID connect, SAML, Swa..etcetera. And the users that are accessing those apps, they can be coming from directories like App Directory and Workday as Marc was just speaking about. They can also be coming in from additional IDPs, Google, Facebook, LinkedIn those social providers. Or generic SAML or Author Open ID connect providers. 

So, as we talk about how we're continuing to enhance our core SSO support, the first topic I wanna cover is Open ID Connect. I'm excited once we've moved Open ID connect into general availability across the product. So everybody that has SSO with Okta will have Open ID connect as a component of their organization. That means that you can leverage the latest authentication standards for the applications that you're building and for your SSO experiences. In the future we'll be adding this into the Okta network, integration network but for today you can still leverage this for any of the applications that you have in your organization. 

We've also been making a number of investments for social authentication. That includes social account linking. So as you bring in a user from Facebook, you're able to link that to a user and after ... universal directory, and you can also fetch access tokens from that social provider. So you can pull in any information you would want out of that social provider. We'll continue to enhance that feature as well and I'll dive into that a bit in the next slides. 

I also wanna call out web accessibility here. This is something I'll dive into a bit in our customizable user experience section. But we've really taken a focus around how we can make Okta accessible for everybody regardless of their capabilities and as a result we've been working towards a full, full compliance with the WK 2.0 specifications, which is the standard for web accessibility. 

And of course we haven't' forgotten about SAML. SAML is still the bread and butter of most of the applications within the Okta network. And we've added things like multiple ACS URLs, which are very helpful if you need to do things like have dynamic call backs for your applications. We've also ... but I'll bring it on SAML certificates. There are certain applications, there are restrictions around the certificates, how they're signed and also the lifetimes of those certificates. So we've brought that functionality into the product so you can generate a certificate signing request within Okta, give that to your certifying authority, get it signed and then upload it into Okta and use it for your applications. 

Lastly we've been moving the Shot 256 SAML Certs across the board. This is a long process but something that we're working on for all of our SAML applications. So that covers the recently delivered items. But now I'd like to talk a bit about what's coming in the future. So on the screen you'll see your generic Okta login screen connecting you to Okta. Many of you have probably seen this today. And for a lot of our customers, this covers most of their need. But for some people they have much more complex integrations than simply a simple Okta organization that users need to connect to. There may be multiple Okta orgs connected to a single log in or the social auth providers that I've mentioned. Or there could be integrated Windows authentication using desktop SSO, or additional SAML IDPs connected. 

And so for those customers that have these complex use cases they generally need to decode custom implementations to handle connecting all these different IDPs together. I'm excited that NASA will be building this into their product in a feature called Identity Provider Discovery and Routing. And what this will do is it enables you to route users based on the device they're using, whether it's mobile or desktop, the network they're accessing whether they're using a VPN or off network. And also the application they're trying to access. Based on those attributes you can route users to different IDPs depending on those requirements. So, for instance if you're using Airwatch for device trust, you can route users on mobile devices to Airwatch to get that authentication and then bring them back into Okta. 

We're gonna go further than that and allow you to route based on individual users. And that way you can specify based on the users domain or even a custom attribute for that user, what IDP they should be connected to. And this will all be supported as a policy framework within the Okta dashboard so you can configure and control very specifically where users go. This feature will be going into beta very soon. If you're interested in learning more come talk to me afterwards or head to the access hub in the expo hall and they can talk to you about it there. We have sign ups available so you can get on the list of information and become a part of the beta program. The actual functionality should be rolling out in the next couple of months. 

And now onto social ops, something I mentioned a few times. Today we support Facebook, Google, Microsoft and Linkedin as social authentication providers, but that doesn't meet the needs of all our customers. So soon we'll be adding Twitter as another authentication provider. They are a bit of a unique implementation so we'll be building that one custom as a part of the product. We're also making enhancements to our developer documentation in our Quick starts so it's really easy for you to quickly read through the documentation and get set up with social documentation for your organization. But as we see more and more people adopting our social authentication products, we found that there are unique cases for each of those customers and that their user base might look different from the user base that we expect as a whole. So we'll be building generic a lot too and Open ID connectors for you to connect any identity provider that supports those standards. And that means, regardless of your use case, whether you need GitHub or Atlassian or someone else's identity provider you can connect that to your Okta organization. And that's again something that will be coming in the future. 

So that covers a lot of the enhancements that we're making to the core SSO product. There are many other things going on but, in the interest of time, continue to push on and talk about customizable user experience. So this is an area where we've seen a massive amount of enhancement over the past year. We've really doubled down in ensuring that you can fully white label your experiences with Okta to make it look like your own organization. So we'll walk through today what we've done around personalization and self service and also how we equip admins with more of that customization to give a true seamless experience for logging into your Okta org. And then lastly I'll cover a brief section on increasing security and easing user adoption through using dashboards to enable users to understand what's going on with their own accounts. 

So when I'm talking about the customization that we've built, I'll take you through a bit of what we think about when we're customizing a specific login experience. On the right you'll see a customized sign in page, but there are a number of different contexts and bits of information that go into that customization. So the first is the application context, that's gonna be, what protocol is that application using? Perhaps it's Open ID connect. And also what, what device is the user on? Is it a mobile device or desktop or something like that. And there's the user context. Where are they in the world, what groups are they a member of and what permissions do they have? What language do they speak and how should we customer the user experience as a result of that? 

Third is the security context and that's where, for certain users or certain applications or resources or certain conditions we may need to require an additional level of authentication through MFA when users try to log into the application. And lastly there's the customer hosted pages. And so for this context it's whether the actual login screen is being hosted on an Okta site or on an external site that needs to log into the organization. Based on those four components we offer full customizability for what that experience looks like. If you're on the right, you can see that a user could log in with Facebook or Google, enter a regular username or password or even with the new feature that was mentioned in the keynote, sign up and actually register for an account for this organization. So that's what we mean when we talk about customizing the login and sign in experience. 

All these things serve the theme of making Okta yours. Making it a seamless experience for your users. I'll walk through a few of the recent enhancements that we made in that space. So, first is extended sign in customization. We have a full customization going into beta but we've also made a number of enhancements recently to add additional links and colors and things like that into the sign in experience where you can customize directly from the Okta dashboard without needing to write any additional code or HTML or CSS. 

We also launched custom email domains. This is a pretty great feature because it allows you to send Okta emails from your own email domain. And I'll walk through what that looks like in a slide or two. And lastly we've added email translation customization. So, now you can customize email templates that are sent out in any of Okta's supported languages. That means that before you could only customize those languages in English, now you can customize all the emails that we might be sending. 

Next component is Okta Everywhere. So we wanna ensure that we can connect any company to any technology and in service to that goal we've added Microsoft Edge support, browser that we're seeing massive adoption for and we expect it to be one of the most popular browsers on our platform. We've also extended the translations that we support, adding new languages, we've added six over the past year, and we've also gone through and enhanced some of the existing translations we have to ensure that they meet the standards that our customers have. 

And lastly there's investments and accessibility. As I'd mentioned we really wanna see Okta everywhere. It means that anybody regardless of their capabilities needs to use ... be able to use our product. So, we've made a lot of advances in our user experience to ensure that the product is accessible for everybody. And then within security we've added a new device notification email, which is an email that you get when a login to your account has occurred on a device that we don't recognize. It helps notify you if there may be a potential security issue with your own account. And we've also added lockout emails for end users. The reason that we've added this is to help end users get themselves back into Okta if necessary. We've found that a number of help desk and support tickets are generally created when somebody gets locked out. And often the tools are within their grasp to fix that issue and so, by sending these emails to end users and giving them the exact steps they can follow to unlock themselves it helps to reduce help desk support tickets for a number of our customers. 

So a lot of stuff that we have delivered recently but there's even more coming soon. So the big, the big one is really showcasing your brand with custom HTML and domains. So we'll offer full skinning of the Okta login experience, registration air and recovery flows as well as the domains that you access Okta on. So that means that instead of seeing this normal login skin you could have something that's fully customized with specific information about the users that may be logging in. Additional links that they might wanna link out to or anything really that you can dream up. I'm pretty excited to see what people build with this and how they customize Okta for their own experiences. 

And no longer will you have to log in at any org at Okta.com as you can see in the top left. We're actually gonna be rolling out the capability to have customer URL Eld App names. And you can have any org.com/login on any domain that you own as the entry point into your Okta system. Both of these features are going into beta in the very near future. Again if you guys wanna come up and chat with me afterward about these features I'm happy to take you through the functionality when they'll be available and how we can help you make the best white labeled experience of Okta for your organization. 

Once users get logged in to Okta, there are also a number of ways that we've been, we've been working to enhance that experience. One of the big questions that we've had is how we can help users on their first day, understand what they need to do within Okta. It can sometimes be a little overwhelming if you just see 50 different applications you need to use. And not really know what the applications are for, whether you're allowed to access them yet or why they're there. So a feature that we launched a couple months ago that we've seen massive adoption for ... it's actually been the most requested feature on our community site, is what we call admin managed tabs. And so what this feature does is it allows admins to configure specific tabs for users to see the first time that they log into an Okta organization. And it means, instead of getting this massive list of applications you can get a targeted list of applications or a categorized list of what those applications are actually for. 

So in this example the admins actually customized the dashboard for a day one experience. On the fist day you log in you would see workday, ADP and Google Apps. That way you know, "Okay, I can go to workday, maybe set up some profile information, log into ADP, configure my payroll information." Because that's one thing you definitely wanna set up right away, and then you log into Google apps and check your email. We're gonna be enhancing this feature to allow you to configure the tabs for any user, whether they're a new user of existing. And this is available in EA Today, so you can contact your support team to get it enabled. 

One other recently delivered feature which I mentioned is sending emails from your own domain. So, for the longest time, when you get an email from Okta, it's from [email protected]. That's not always the most helpful thing that says, "Hey you're locked out of your account and you can't reply this email with any, with any questions." So we've actually added the enhancement to use your own email domains and configure who the email sender is for any emails originating from Okta. You can set something up like [email protected] with a monitored email address and configure those sender names so that your users see that the email is actually coming from your own organization instead of from Okta. And that's available in the EA today. 

Moving on to some things that are coming in the future, we wanna continue to enhance the feature set around making it easier for users to adopt the product and understand where they need to go the first time that they log in. So, we're gonna be building an Okta enrollment flow that is tailored to your users. We'll take the policy engines that we have for registration and other components of the product and apply those to the enrollment flows, so you can do things like not require your users to select a security question, which many people requested. And you can also allow users to customize the languages that they see, even in their first enrollment flow so that everything will be translated into their own language. And once they do log in, we're also going to be building a feature called Admin App Notes. It sounds pretty innocuous but it's actually a very powerful feature. We went out and spoke with our customers to find out where they got the most help desk tickets within their Okta implementations. And two of the most frequent questions we've found people answering. Is, why do I have an application? And who can I contact if I have an issue with that app?

So Admin App Notes will allow you to configure specific information about an application that's visible on the dashboard. And you get users' information like in this example, it tells you why you have ADP on your dashboard and also, who you can contact if you can't log in or if there's another issue with the application. That means that users can go directly to where they need to get help instead of needing to contact a help desk first. 

So this is a bit of a transition but moving to the global workforce, I'd mentioned a few things about the languages we've added and the translations that we're working on enhancing but for update it's really a key part of our product. That we need to enable Okta features across the board. We have millions of users authenticating everyday, from 185 different countries. And they leverage all the 23 languages that Okta supports. But in 185 countries there's a lot more than 23 languages that people speak. So, we're going to continue to build and invest in customization around translations within the product. 

We're already working on additional supported languages for instance Turkish is coming very soon and we're going to add more and more as customers demand specific translations. But, as fast as we might add new supported languages, we won't be able to cover every need for every customer. Because an individual customer might look slightly different from our general customer base. So, as a result we're going to offer localization, customization and the capability to bring your own language. And that means that you can not only control specific translations that we already support within a product, in case there are regional variations that you would like to support, but it will also allow you to upload any language for any size of strings that you want within the product. Providing you that full customization for any country or region you may need to deploy Okta in. 

We've also seen heavier and heavier usage of Okta Mobile especially as we move abroad. In certain countries there's actually more usage of the mobile product than there is of the desktop product. So we'll be enhancing Okta Mobile to support localization as well. And for all these end users, as people are using Okta more often we find that it becomes more important for them to be engaged in their own security and able to understand any interactions that may be occurring on their own account. So we're going to empower users to manage their security through a security dashboard. You've probably seen this in a number of different products. But the idea is, as you log in you can see information like what two factor authentication methods you have configured and also an activity log of what's been occurring on your specific account. So you can see if you have a login from an area you don't expect, one of those new devices that's logged into your account or something like that, and will also provide links and calls to action for users to remedy any potential situations or scenarios they may see on their dashboard. 

The idea here is getting back to that same concept of helping enhance the Okta deployment and implementation strategy, such that you have lower cost in the actual usage of the product. And so that covers our customizable user experience section. But now onto my favorite product, which is API Access Management, this is the future of application development. And so our industry standard OAuth 2.0 support and it utilizes a scalable and powerful authorization policies to enable access to APIs. And it's all provided through developer friendly APIs and widgets for the applications that you're developing. 

The real unique thing here in the shift is that previously we would talk about authentication and API Access Management is authorization. So it's not just who you are but it's what you can do. We launched this product a year ago, and initially the focus was really around internal applications that you were developing to access your resources. In that way if you're building a custom application for your sales people to access a CRM database, it can be secured through authorization policies built within our custom authorization servers. But over the last year we've added many enhancements to this product to cover a much broader scope of applications, whether it's third party developer applications, meaning if you have APIs that you've built that developers what to utilize that don't even work within your company, they can do so and that can all be secured through API Access Management. Providing a fine grained control of authorization policy for clients that you may not be billing yourself. 

We've also added support for IOT style devices that are connecting into Okta. IOT is a very broad and amorphous word and it can mean a lot of different things for a lot of different customers. We have basic support today for dynamic client registration, but in the future we'll be moving more to support client credentials flows as we do today but also new registrations for devices as they are printed and manufactured. And we'll get into more of that in the future, but for today we do have some basic IOT support. 

So let's dive into a few of the recent enhancements in the product. A lot of these enhancements have really been around ... allowing you to leverage your existing identity investments within your Okta organization and build certain portals outside of Okta. Because we found that for many of our customers it's not just the identity team that needs to use API Access Management. It's an application development team, It's the identity team, and it's a research team that owns the APIs. Okta becomes the nexus for that authorization policy but there are many different organizations and teams that are interacting with the elements of APIs and they might not all have access to Okta dashboard. 

So we really had to focus around enabling external portals where you can build, app developer portal outside of Okta that enables people to configure applications and access policies without needing that Okta admin login. So we've added Dynamic Client Registration, which is the ability to create and control Auth and IDC clients from outside of Okta utilizing an API. We also added extensible custom metadata. So as we have these new clients and applications being created we've added the capability to put custom information about that application directly on ... within the Okta database. So you can add things like groups that matter for that application or contact information for that app. And this is an extensible data store so you can basically add any structured data that you would like to those applications and leverage them for other components of the application you may be building. 

We've also added configurable client IDs and secrets. This is something that's really for a migration use case. We found that many customers are moving off of either a homegrown API Access Management platform or another vendor and to ease that migration we've allowed those customers to configure the client IDs and secrets so they don't need to rewrite those in their applications. Of course you can still go for the more supported and preferred approach which is using new client IDs and secrets for the migration but this just eases some of the migration pain for certain customers. 

We've also added relying party initiative logout. This feature allows you to log of out an individual application and then trigger a log out for all of your Okta org. And clients secret authentication ... we are constantly looking at the newest evolutions in OAuth and Open ID Connect and we wanna ensure that we're adding new security layers to our OAuth product. One of those is additional client authentication method using client secret jot. And, for those of you in the room not familiar with Open ID Connect and Auth sorry for running through a lot of detailed technical terms. I'm happy to chat with people afterward about them but just with that caveat. 

So, now onto the authorization servers. So this is the policy side. This is when we have those applications, how do they access APIs? How is that controlled within Okta? We have a comprehensive management APIs for the authorization servers. Again that's going back to allowing those external portals outside of the Okta admin experience to create and configure policy and applications. We've added application groups and tokens. So, many people might need to build an application that's customized based on groups that his user's a member of. Maybe they're an admin and they get an extra button that they can see. So, we've extended our group support to utilize application groups. So that would active directory or workday or other IDPs that may be connected and plug those into the same token experience so you can fully customize that access. 

And we've added enhanced claims control. This requirement has basically come out of additional deployments that we've seen from customers where they want to have fine grained control of the way that we build identity and access tokens for OAuth. And control the size of those tokens at different scale, so you can tune the performance based on the needs of the specific implementation. With these features that we've built we're really moving toward a place where you can have an entire third party developer ecosystem built around your APIs. One of the last pieces of that puzzle is OAuth user consent. This is something that many of you have probably seen before if you've tried to log into an application with your Google account or Facebook account. You get a prompt that says, "Hey, do you want to allow this application to access your profile information on Facebook on your behalf?" So we're building this functionality as a generic part of our platform. 

And what this looks like is this little example I'll show you up here. So let's say the Okta organization is a company called ATCO Solar. You build solar panels and you put them on people's houses, they generate electricity. You've also built a number of APIs and those APIs provide information like the electricity, the amount of electricity that's generated off those panels and how much is fed back into the grid. You may be exposing those APIs to outside developers. For instance, the Board of Public Works and Electric Utility may wanna build an application that accesses information about those solar panels. Two different companies, the outside company wants to access your confidential information. The way we would do this is through user consent through OAuth. The idea is, if you have this user, maybe you're a home owner, home owner named Mark you log into the Board of Public Works applications and you will get a prompt like this one up her and it would clearly show you that you're Mark, you have this Board of Public Works application and it's requesting permission to access your solar panel information as well as your profile and billing information. 

You can evaluate on the screen whether you trust the app, you can see your name on the top, so it looks like you're logged in. You can see the ATCO Solar in the top left so you know that that's the organization that you're gonna be providing access to. And you can read what exactly that application will get access to. You could even drill in a bit more and get specific information about what those permissions mean. And then you could choose, based on that information to either allow or deny access. This puts security in the hands of the users and allows them control over what applications are able to access of their own information. This feature will be going into beta very soon. I am actively working on recruiting customers for this feature. So if you're interested, and you have a use case where you have either third party developers or a high level of security that you wanna provide for your users, please come talk to me. 

Some of the other things that we're covering and will be building in the near future, token management APIs. So this is basically, as you're building out more and more applications for third party developers, having control of those tokens that are issued. Some of you may have seen that a few months ago there was a phishing campaign around Google Drive with their Auth implementation where people were getting access to Google Drive information based on fraudulent applications. As soon as you identify that those applications may be fraudulent you can easily revoke any tokens or access that was granted to those applications through a token management API, which is a functionality that we're building today. 

We're also going to be building OAuth for Okta APIs. We have this great platform for authorization policy for your own APIs and we're gonna be extending that to the internal APIs that you have for managing your Okta organization. And there are additional things that we'll be building for OAuth and Open ID Connect including extended policies, token preview and encrypted jots. All of these go in service of making an easy experience for you to configure those authorization policies and understand how those will actually impact the applications that you've built or will be building. And we will also be adding java search and flow which is basically SSO federation for your tokens. 

Looking a little further ahead we're gonna be continuing to invest in gateway integrations. Almost every API Access Management customer that we've worked with is using an API gateway. And Okta is not a replacement for those gateways, we're a complement to them. So you can use that gateway to actually manage your APIs but the authorization layer will sit with Okta. And so we are building gateway integrations with Apigee, AWS and Nimsoft to ensure that we can plug into the gateway vendors that our customers are using. 

We'll also be building token exchange support. In some cases you may need to generate access or identity tokens within Okta, but then exchange one of those access tokens with another token providing system in order to provide the right access within your application. Industry standards and industry specialization is something that's really important within OAuth. There are many different draft standards within the OAuth and Open ID Connect space around support for different industries and we're tracking those closely. In particular there's the smart on fire standard for healthcare and also the financial APIs working group, which is helping to find standard patterns for OpenID connect implementation within these industries. And we're gonna be watching these closely and making investments to align their support with our product. And, along the lines of security will be watching token binding and the draft standard for token binding which is basically supporting veri tokens for OpenID connect. 

And lastly there is the step up authentication for OAuth. Sorry I'm skipping through these a little quickly, we're running very tight on time. So, there's a lot of stuff we covered, and as you can see from the slide at the start, we started out with something very simple, employees connecting to applications and it's evolved to connecting users from any location, users in any directory to many things other than applications, networks and APIs et cetera. We've made massive enhancements across the board on all of these and I'm excited to share all those with you. And I'd also like to call out, we mentioned five new betas that are available. I don't think we've run these many betas in parallel before. And I'd really love for you guys to go sign up for these. So we've got Eld App interface, Custom URL domains, Custom Hosted Pages, IDP Discovery and Routing and OAuth 2.0 consent. So all those are available for signing up today. 

And with that we're out of time, I wanna thank you so much for walking through, or sitting through my talking very quickly. If you have questions come chat with me afterward. Thank you so much. Cheers.