Oktane19: Roadmap: Why Building Customer Identity is Hard (Use Okta Instead)

John: What I wanna talk to you about today is basically why building customer identity is difficult. Hopefully by the end of this session, I'll convince you that Okta is a great solution for you to use when you're building customer identity in your own application. What we'll walk through today is going to be a bit of background on the complexity of building an identity solution, and then we'll go into the different components. We went forward one but that's fine. We'll go into the different components of building an identity experience in your application, user creation, migration and storage, access and customization, the developer tooling that we offer, and then also the reliability scale and security that you get when using an identity service like Okta.

John: For some folks, building identity into an application might just be a username and password. That's pretty simplistic, and the reality is you'll need a lot more as your application scales to properly deliver identity within that app. First, you'll need to identify a user who they claim to be with a username, and then you will need to authenticate that user using some credential that you trust. In many cases, it's a password but it could be something like a SMS message, an email or some of their push factor, second factor verification. You may need to enroll that user in additional credentials or additional profile attributes about who that user is.

John: As you saw in the keynote demo today, often when somebody signs up the first time, you want to gather a minimal set of information, and then progressively profile that user over time. You also need to maintain a life cycle state of user. They could be active, deactivated, deleted and things like that. Lastly, once you've got all of those steps completed, a user needs to be authorized to access either an application, a resource, an API, a server, something like that, and so really identity involves a lot more than just authentication. Okta can help make it easy for you to include that on your app through a set of customizable building blocks for any identity experience.

John: Today, we'll walk through what those different building blocks are and some of the recent enhancements we've made to make this a great platform for you and what we'll be doing in the future. The reason we're talking about this to you today is that we've solved logging in at scale before. Many of you have probably seen this before. We call it the Chiclet Dashboard. It's how you SSO in the applications if you're using Okta for what we call our workforce identity side of the house, but the reality is in building this application, we had to solve a lot of scale issues around having a large authentication system and identity platform underlying our application.

John: We figured out how to manage multi-tenancy, multiple different users, credential types policies, integrations into directories, and a whole host of other solutions or issues that you run into when building a truly scalable identity platform. What we learned along the way is like building identity yourself can be error prone, costly, and slow. Many of our customers are comparing using Okta against building identity in house. What we've seen through the research that we've done and through external sources is there are a lot of issues with that? First of all, it's error prone. The number two issue on the OS top 10 of security mistakes is broken authentication.

John: When you have broken authentication, that's a pretty big problem for people accessing your app. We also have seen, and many of you have probably experienced, that software development projects often run over budget, and based on research by Standish, that overrun is on average 200%, and also things run late. 70% of IT projects have a schedule overrun as well, so things end up being error prone, costly, and slow, but doing identity right is crucial for your business. 85% of customers are loyal to brands who they trust to safeguard their privacy and personal information.

John: When you do identity right using a cloud identity solution rather than a legacy solution, we find that it's much cheaper. Your total cost of ownership can be one third of what you might be doing when you're building in house or using some other legacy solution. Lastly, when you break that trust with your customers, 69% of them will abandon business dealings with a brand following a major data breach, so getting identity right is extremely critical to your business, and using a good identity service can help you unlock innovation. You can deliver a frictionless experience to your customers with consistent experiences across applications, and simple registration and authentication flows.

John: You can get to market faster meeting your project timelines and maximizing the few developers you have to be as efficient as possible. You also have centralized management of identity, so no longer do you need to deal with multiple disparate identity solutions. You can bring them all under one simple management pane of glass. Lastly, using a service like Okta, you get internet scale security. Our job, our business every day is paying attention to identity and security, looking at the latest breaches in the industry and how we can best react and deliver the best solution for you. All of these together mean that Okta has helped building a secure identity service for you to use as part of your application.

John: With that marketing intro, some values of why you might care about this, I'd like to jump into what you're actually here to hear about today, which is our roadmap. What are we building? What's going to be coming in the future, and how can you best leverage this as a part of your applications? First part of that is user creation, migration, and storage. You can't begin a user authentication journey without having a user in your application. User directories can take three main forms within Okta. The first is universal directory or UD. This is kind of the bread and butter.

John: This is what we use every day and how we store users within Okta, but many of our customers also use external directories. They may be connecting active directory, LDAP or even just some database to Okta in order to have a user story that they may have already deployed prior to working with Okta and just connect it to a new identity system. The third form of user directory is a federated identity provider. We started out with this by supporting SAML2 identity providers but have now expanded to support social identity providers like Google, Facebook, Microsoft, and also OpenID Connect compliant IDPs.

John: Across our different customer deployments, we see many different permutations of these types of directories, and Okta can help orchestrate all three of these together into a single control plane. I'll go through each of these in steps to explain things that we built recently and what will be available in the future. Let's start out with UD. The main focus over the past year has been adding additional flexibility to universal directory. As we've evolved into more of an identity platform, we've tried to give you additional flexibility on how users can be created in universal directory, and ultimately how you can break apart different concepts of what those users are.

John: One of the main components of that is decoupling users from their credentials. In the past, a user could be in a password reset state, which can be a little confusing because the password has the issue, not the user themselves. The user may still be active, so what we've looked at doing is decoupling those such that you have credentials and then you have a user who's associated with certain credentials. It gives you flexibility to do things like you saw on the demo this morning where you have a password list user or a user that doesn't even need to have a password initially.

John: In the future, we'll be introducing user types, which is a way to have different types of users within an Okta organization within UD. We have groups. Many of you use groups for different types of solutions, but user types are a little different. It's a way of introducing a mutually exclusive concept of what a user is. You could have customer users and employee users that have different profile attributes and different credentials associated with them. You could have service account users that you also define in a slightly different way. User types will give you a way to hang different policies off of those types of users so that you can deliver the right authentication security experience for those user types.

John: We've also released additional registration and progressive profiling capabilities, where you can now have users sign themselves up for an application or your organization and progressively gather additional information about those users over time as you gather their trust. Someone may not want to give you their home address the first time they meet your brand, but over time as you build that trust, you'll be able to gather that information and augment user profiles. That's all going to be a major component of the universal directory.

John: Lastly, looking into the future for universal directory is the introduction of new entities as a part of UD. That's going to be things like devices, so no longer is universal directory just a user directory. It's a true universal directory where you can have many different types of entities that would be stored within UD. That'll be much further down in the roadmap, but the direction that we're going is that we want to enable you to control access to many different types of entities, and UD will be at the core of that.

John: I'd like to talk about those customers who have an existing user story that they might want to leverage with Okta. There are two different options here. One is import those identities into Okta, and the other would be maintaining an existing system, and we have solutions for both. If you're trying to import users into Okta, you can use our API credential import capabilities for passwords and OTP seeds and also HR systems and HRS master. In the future, we'll be introducing additional policy control around things like import hooks, so you can define specific runtime behaviors to define what happens to a user as they're created with an Okta and also an unknown user hook so that you can call out to an external service and make determinations about what you want to do about a user that you have not yet identified.

John: For maintaining your old system, you have our existing inbound federation capabilities, which I had mentioned as well as directory integrations into AD and LDAP. In the future, we'll be introducing a roadmap item for authentication hooks where you can make a runtime callout to an external database to authenticate against that database. At that point, you can make a decision if you want to create the user in Okta or maintain them in that external database. That gives you the ultimate flexibility to take the users that you may have existing in any system and have them authenticate into Okta, and then use our powerful access policies for what they may need to do next.

John: The last component of our directory story is social authentication and inbound federation. One of the most powerful components of using an existing identity provider is that users are able to easily authenticate without needing to sign up for a brand new account. I'm sure most of you in this room at some point have used a social identity provider either to sign in with Google or Facebook or something like that into an application. We offer a wealth of choices here, starting out with those I mentioned before, SAML IDPs, but as we move into the consumer identity space, we've needed to add more IDPs.

John: We have social authentication providers like LinkedIn, Google, Facebook, Microsoft. Recently, we GA our OpenID Connect functionality to connect any OIDC compliant identity provider to Okta. This is just a sampling of the different IDPs that you can support with that new functionality, but the idea is that you get powerful out of the box configuration for existing identity providers. Outside of this, you can also bring in enterprise IDPs that may be using the OpenID Connect or SAML2 standards. On the roadmap for this year, we'll be introducing an OAuth2 IDP, giving you even more flexibility for the reality that a lot of social providers out there and many existing identity providers that may have been built in house aren't actually OIDC compliant, and so with the OAuth2 standard, you can have more flexibility to collect even more identity providers to Okta.

John: One of the underlying assumptions that we have when building these IDPs is that we want to minimize the required attributes for creating users. What that means is once again it's easy to sign up. You get that low level of trust required for your initial interaction with a brand, and then over time, you can progressively gather trust and data from those users as they learn to interact with your application. That can all be orchestrated within Okta using our identity provider capabilities. On top of that, something that's often overlooked with social IDP is the power of account linking and user creation policy. You can define policies within Okta for creating a new user the first time they federate into an Okta organization and also how they may be linked to an existing account within Okta.

John: Coupling all of these features and functionality together gives you a powerful solution to increase registration or retention. We've seen in the industry 20% to 40% increases in user registration and user retention through using existing identity providers. That's all the background I have on the directories, but one thing I want to talk about that's come up a few times both in the keynote and in this session so far is thinking about trust and user privacy. Protecting users' privacy goes beyond just a checkbox. A lot of people are thinking about GDPR, impending legislation in the United States and abroad about how they can maintain user profile data and privacy alongside an identity system.

John: Anytime you're thinking about Facebook or Google, you're probably thinking about privacy and consent. To provide a framework for thinking about what consent really means, I wanted to bring up the four main tenants of a GDPR compliant consent, and that would be consent that's freely given where the user isn't pressured into giving that consent. It needs to be specific so the user understands exactly the data that they're giving consent to share, needs to be informed such that the user is clearly agreeing to the data that they're giving as well as how that data will be shared.

John: Lastly, it needs to be unambiguous, and this is something that's really hard for some people to grok, but unambiguous means it's clear. You'll see these terms and conditions that are thousands of words long. You have to scroll through them. They make no sense, and you don't understand what's going to happen with your data. In the words of GDPR, that's not a compliant form of consent. The user needs to easily understand how data will be shared in order for the consent they are giving to be compliant.

John: We're going to be pursuing three main areas of investment for enhancements to support user privacy and consent. One is going to be core product enhancements, looking at how we can enhance the universal directory and our other product capabilities to support consent management within Okta's products, but in the meantime also be investing in the industry partnerships with existing consent management vendors to integrate their workflows into the Okta product. Lastly, our professional services team will be available to help individual customers deploy consent management in the way that makes the most sense for the regulatory environment in which they operate.

John: The reality is there are going to be many different regulations around consent management, and there may need to be custom deployments for each customer. We'll work with you to provide the solution that works best for your organization. Now with that, we've covered the creation of users components. I want to bring Wills Dawson up on stage to talk about access and customization. Thanks guys.

Wills Dawson: Thanks. Is that working? Hi everybody, my name is Wills Dawson. I'm the senior product manager working with John on the identity platform, and I'm excited to talk to you today about access and customization. When our customers use Okta to protect and secure a seamless access to their applications and data, often that journey for the user varies customer to customer, and the experiences are often different between the applications even within a customer. I'm going to spend the next few minutes sharing different ways that you can use Okta to craft the right experience for your users and make sure that they're being successful.

Wills Dawson: Contextual access is where this starts, and this is not a new thing for Okta. We've had this for a while. We've been able to take contexts that you have about the user, the device, the group, the network, and run that through an adaptive policy intelligence to output a decision for accessing that app or the API or the other resource that the user is trying to access. That's really valuable because it provides all this flexibility that you need out of the box in Okta via configuration so that you don't need to write code to do all of these things. You may output some multifactor authentication decision.

Wills Dawson: With a beta factor sequencing that's available today, you can actually define the specific factors that a user will see as they go through their user journey. While that's great, we've noticed some gaps and some problems and some points where it's not as flexible as we might like and some of you might like. For example, the application that you're trying to access or the resource that you're protecting is often an important part of the decision that you would make to prompt for multifactor authentication or deny the authentication. It's really more a part of the context than it is a protected resource.

Wills Dawson: A second gap that we've noticed is around credentials. As you saw in this morning's keynote, we're now able to take a user that doesn't need to have a password at all. It's a particular problem in some industries where you have applications that users may not be trying to access frequently, and they may always go through a password or often go through a password reset flow anyway, so you want to use different factors, or potentially there's account takeover scenarios or concerns, or you want to avoid passwords all together.

Wills Dawson: That's why we're really excited today to introduce you to the Okta identity engine. It's a set of customizable building blocks for any identity experience, and powers a dynamic context base user journey securely and again out of the box using Okta configuration with low to no code. How does it work? It's the same context that we had before with device applications users, and it flows through the series of steps. Starting with identify, we need to know who the user is that's trying to access these applications or these resources, and next in authentication, we can prove that they are who they say they are.

Wills Dawson: Make sure that they have access to this application or this resource. Next, with enrollment and activation, we're able to do things like ask them for new profile attributes that they might need for this application or ask them to enroll in new credentials that they need. Lastly, during authorization, we'll pass that baton to your application via an OpenID Connect token or SAML assertion or some other federation artifact. These steps are great, but the power of the customization is really in these components that are part of each of these steps. I'm going to walk through a few of those right now.

Wills Dawson: The first are policies, so this is familiar from the slide previously, but these access policies really let you customize and configure how Okta will perform in each of these steps, which conditions are appropriate for different steps in this flow. For example, you might have sign on policies in the authentication step that define which multifactor credentials we should use in this situation, again, based on that context, or you might have authorization policies that say which claims you want to include in OpenID Connect tokens or SAML assertions for, again, this particular app under this specific scenario.

Wills Dawson: The next component that I want to talk about are inline hooks. You heard this morning about Okta hooks. One of those types of hooks that we have are inline hooks. These let you write a little bit of code and change how Okta might perform in one of these steps. It allows you to say for example, during a user registration, you may want to verify that user's email address before you let them into your application, or, again, during the authorized step, maybe you want to pull in data from your own application or your own database to make sure that those claims are part of those tokens.

Wills Dawson: The next component I want to touch on are event hooks. This is a different kind of hook, whereas a user is going through this journey in the Okta identity engine. Okta is performing various different pieces of logic, and we're sending these event hooks out to you and your system to make sure that you're notified about these events as the user's going through the process. For example, you might put a user into our Marketo drip campaign for email when they register for an application as you saw in this morning's keynote.

Wills Dawson: Of course, the last component that I'll touch on here is about prompting users. Throughout this identity engine and the user going through that journey, we're going to be asking for credentials, asking for new profile attributes, various things like that. It's a really important component that will let you make sure that you're having the brand and the experience that your customers need as they go through this process. This really unlocks a few different use cases with the Okta identity engine.

Wills Dawson: The first are truly passwordless users. Again as you saw this morning's keynote, we're able to register a new user with just an email address, maybe a first name and last name if you'd like, and have them register for an application, get access to an application without needing a password at all. We're really excited about that. The next scenario that this unlocks is progressive profiling. Again, you saw this this morning, but it is the ability for Okta to have one application that needs certain information and you to specify that another application needs additional information. This helps with something that John was saying earlier about making sure that when users are onboarding into your system that they have this most seamless, frictionless experience possible.

Wills Dawson: Lastly, I'll touch on per app branding. If you have multiple brands or multiple applications that you're showing your user base, and you want different experiences to happen with each of those applications, again, because the app is in the context here and present throughout this flow, you're able to provide that right experience for the right application or the right brand throughout the user's journey. I'll sneak one more component in here that I want to talk about a little bit in more detail, and that's integrations. John touched on it earlier with consent, but Okta's independent and neutral stance really lets us drive these integrations throughout the ecosystem and deliver value to you and your systems and your applications in ways that you want.

Wills Dawson: It really lets you use these integrations to achieve any identity experience possible beyond of what comes already flexibly out of the box with the Okta identity engine. These are just five examples of different integrations that we're looking at partnering with in the industry around bot detection to prevent automated threats, consent management, like John mentioned, identity proofing, device fingerprinting, biometrics, things like that.

Wills Dawson: To recap, we talked about how the Okta identity engine can power any identity experience with its combination of steps, components, and these integrations. Next, I want to touch on a few things that will help you derive and deliver the experiences for your users and help to convey trust to that population. How a user feels when they register for your application and when they access your application is really crucial. If they don't feel like they're having a good experience, they don't feel cared for, they don't feel trusted, they don't feel like they can access the value quickly and easily from your application, they're probably going to leave.

Wills Dawson: They're probably not going to use your application. That affects retention. That affects revenue, and at the end of the day, you all in this room are working really hard on these applications. Like Todd mentioned today, everyone is a technology company. You're working hard on these applications and technology to deliver value to your users, and you want to make them successful. You want them to feel good when they're using your applications. Let's touch on a few areas in Okta and tools that Okta has to let you present that feeling of trust and care and make these users successful.

Wills Dawson: First, I want to touch on communication. This is really your opportunity to introduce yourself to your users, present your voice, and sometimes even guide them through some painful experiences like password reset. They were trying to get access and get value out of your application and they forgot their password. They may need to go through this painful process to reset it, but if you can in that password reset email guide them and keep them safe and warm and secure, they might say, "Oh, that wasn't so bad," and have some good feelings towards you instead of annoyance.

Wills Dawson: We did that with a few different things. The first thing that we have in this communication tool set is a custom center. We let you customize your email domains so that instead of users receiving email from [email protected] when they don't know what Okta is, they can receive emails from you, from your domain. Okta will still send the emails, but it's coming from you instead. We also have dozens of different templates and over 25 different languages in which you can customize and localize these emails from things like password reset to user activation.

Wills Dawson: Finally on the roadmap are things like conditional logic, being able to customize inside the template to say, "Hey, if this user is in this geolocation or that geolocation or if they're using this application or that application, you can customize look and feel the copy of that text to make sure they're getting the right message at the right time, and also adding even more context than we have today, including the full user profile, application context, et cetera. We will also be looking at being able to customize voice messages and push messages. We have SMS customization available today as well.

Wills Dawson: Next, I want to talk about how to get your brand everywhere. It's not just emails. It's not just SMS messages but it's the URL domain. If we are the Rebel Alliance here, hopefully we have Star Wars fans in the room and not too many Star Trek fans, but Okta will allow you to host and terminate TLS on your login site so that all you need to worry about is html, CSS, JavaScript on your login page. We also let you host the application and host the login widget, which you can see faded out here inside your application, but it's oftentimes a lot easier to let Okta host that page and handle all the reliability, security, scalability needs for you.

Wills Dawson: We just expanded our certificate support for customer demands so that we can handle the TLS appropriately in more of our customers and we're excited that this is going to be generally available at the end of this month. Next piece that I want to chat about is our sign-in widget. I mentioned that you can embed this in your own applications or let Okta host it. This screenshot is a tool from our developer website. It allows you to paste a URI into that text box there and the tool will automatically determine the colors from your logo, and brand this experience for you.

Wills Dawson: You can then use the JavaScript and CSS tabs up there at the top to copy that code right into your application or the custom hosted login page that we provide. That login page will go generally available shortly after the URL domains as well. Finally, if there's an error that happens inside Okta while your users are visiting Okta, if there's a Wiki in your seat and robot falls apart, we want to make sure that you can brand that experience according to how you want it, not how Okta should look or wants it to look.

Wills Dawson: To talk a little bit more about these types of developer tools, I'm going to bring John back up on the stage. Thanks

John: Thanks Wills. Don't worry, Wills will be back in just a few seconds. I've got one slide for you guys. Building apps can be complicated, and even though we'd already exposed a lot of tools for you through our restful APIs and our authentication APIs, the reality is having SDKs and integrations is critical to making your developers as successful as possible, so we've been investing heavily over the past two years in different forms of developer tools to give to your teams the technology stacks that they're building. That includes authentication SDKs and integrations across a JavaScript angular react as well as native mobile SDKs and IOS and android.

John: There's also management SDKs to both import or manage users within your Okta organization, or manage other configurations, and we have Java, PHP, and .NET SDKs there. Over the last year, some of the big investments that we've made have included native login support within IOS and Android, so no longer do you need to use a web view for users to authenticate in IOS and Android SDKs. Instead, you can build native UI components to give that seamless experience to your customers as they're using your mobile applications.

John: We've also expanded our API support to cover additional API end points that customers use every day. We also now have a beta OAuth2 for Okta APIS. While that may sound like a bunch of protocol mumbo jumbo, what it really means is that you can enable scoped access for your applications to Okta APIS. It's been a very common asks from our customers that they don't want to give a super admin token to some application that they're building. What the OAuth2 APIs enables you to do is have specific scope to access for a given client to certain Okta APIs.

John: Over the course of the year, we'll be rolling that into our existing management and authentication SDKs as necessary, so you can do things like profile management, build the developer portal or implement other solutions necessary for using Okta's APIs. The other exciting thing that we have on the roadmap for this year is a custom factor SDK, also known as an MFA SDK. This way from an IOS or android app, you can actually embed a custom multifactor authentication experience into your own application. Instead of directing your users to download a Google authenticator or Okta verifier or some other solution, it lets you give a fully branded experience for authentication to your end users and to your customers.

John: Now, like I said, I have one slide. You get to talk to or hear from Wills in just a second. If you want to learn more about this, because this is really a huge topic and I'm not doing it justice here, tomorrow at 1:00 PM, Nate Barbettini our PM for developer experience, will be diving very deep into this roadmap. I encourage you all to go attend that and learn a bunch more about what we're doing in this space. With that, I'll bring Wills back up. We'll talk about reliability, scale, and security.

Wills Dawson: Awesome. Thanks John. Okta has all of these things, user storage, migration and creation, access and customization, and these developer tools that John just talked about. With all of these things that Okta has, when your application becomes wildly successful inevitably with a million users, 10 million users, 100 million users, can Okta scale to support that? Can Okta be reliable? Can Okta secure all of those users? John touched on this at the beginning, but that's actually where Okta shines. We have high scale requirements across all of the different types of deployments that Okta sees, whether it's business to employees, business to business or business to consumer.

Wills Dawson: You look at MLB, who you heard from this morning, enhancing the digital experience for tens of millions of fans, having their opening day last week that went very successfully, or Albertsons migrating millions of users and consumers to Okta from legacy directories, or Hitachi, securing access to over 300,000 global employees across hundreds of different domains that are distributed around the world. These are some very complex use cases, and so how does Okta meet these demands really comes down to three different things. There's reliability, scalability and security.

Wills Dawson: Reliability is Okta's ability to be resilient to failures, however catastrophic they might be. With scalability, we think about the different types of loads or traffic that we'll get, whether that's a burst or in a sustained type of model. With security, it's about prevention, detection, and monitoring, and responding to those threats. First, I'm going to touch on reliability, and that's really about redundancy going all the way down. Okta has built cloud first cloud only on AWS, and that really redundancy on AWS starts at the DNS layer. We actually have two DNS providers in case one of them goes down, so even if there's an issue at the DNS layer, we have redundancy.

Wills Dawson: Then on all of our servers, all the way down the stack, whether it's routers or load balancers or database servers, we have resiliency and redundancy there to make sure that if one server goes down, the Okta service will still be up and running and available for you and your customers, but it doesn't stop there. We actually have three sets of this across geographically separated data centers within AWS. All of this is going on within one AWS region, but how AWS deploys is actually in different data centers. This means even if one or two data centers go down, the Okta service is still up and available.

Wills Dawson: All of this is just one active part of the Okta service. Even if there is a geographically oriented or even if all three data centers go down, if there's a regional outage, Okta can fall back to a disaster recovery region and still come back and be available for you and your customers. All of that is just in one cell that we have globally. We actually have several cells globally, and with all of that infrastructure in place, we just launched a cell in the Asia Pacific region last month, so we're very excited to be able to better serve our customers there.

Wills Dawson: This is more than just scale. It's about response times and data compliance and locality concerns as well. Finally, I'll touch on security. We think about that in three different ways. There's defensive security, which starts from hardened infrastructure, secure code practices and training for developers all the way up to the product features that we'll build and put in your hands. Additionally, we have teams constantly monitoring the service, making sure that it's safe and reliable. Then finally, we'll also have incident response sometimes on a per customer basis.

Wills Dawson: If we notice a particular attack occurring against one of our customers, our team is there for you and to help you. With offensive security, this is really thinking like attackers, so we have an in-house research team that is doing industry research into this space and also responding to breaches that happen in the industry. We have postmortems to make sure like, "How would Okta respond if that were to happen at Okta, and what sorts of safeguards can we put in place to prevent that happening in the future?"

Wills Dawson: We also have internal and external penetration testing teams and a bug bounty program that we run as well. Finally, with trust and compliance, we have policies and processes in place like building security, physical security as well as InfoSec training company wide. We also go through internal and external audits, and it leads to certifications like Soc 2 Type 2, ISO 27001, and several others.

Wills Dawson: Thanks for your time. I want to bring John back up for some closing thoughts.

John: Thanks, Wills. All right guys, thank you so much for listening to us walk through the roadmap today. I hope we did a little bit to convince you about why Okta is a great identity service for you to use when you're building your custom applications. Our key takeaways from today, we talked about how you can create users and leverage existing identity providers to make it easier for new users to sign up or to bring existing users into your Okta organization. We walked you through access and customization, including the Okta identity engine as well as all the customization features that we have going GA very soon.

John: I walked you through very briefly our developer tools. You can learn a ton more about that at Nate's session, and then Wills gave us a quick run through of how we think about reliability, scale and security across the organization. Everybody, get your phones out. This is the slide next that you want to take a quick picture of. There's a lot of new features that we talked about, and we didn't call every single one out along the way. This list isn't even exhaustive, but what I wanted to give you a second to do is just take a quick picture of many of the different things that we released over the past eight or nine months, and have an opportunity to after this session, go and check them out.

John: You can go to our developer site. You can reach out through your CSM for support, or you can come chat with us afterwards. All of these features are available, and we're excited for you guys to test these and see what you can build using these features and the underlying Okta identity platform. My closing thought is you guys are all building amazing applications. You're all technology companies. I'm so excited every day and through this conference to hear about all the great stuff that people are building on top of Okta.

John: You keep building your products and doing amazing things, but trust Okta to handle your identity solution. We're thinking about it from an end to end process where we can ensure that you can build the trust with your organizations through trusting us to deliver identity and authentication in a secure fashion. Thank you so much. Have a great day, and I'll bring up recommended sides or a session slide for afterwards. Thank you.