The Future of the Okta API, our DevEx and API Access Management

Claire:  I'd like to introduce Alex Salazar. Alex is the VP of developer products at Okta. He was formally CEO at Stormpath, which merged with Okta in February. We are super excited to get a preview today into the roadmap for our API products.

Alex Salazar:  All right. So every company large or small across industries, they're all driving towards delivering their products and services to their customers online and to do that, all of them are having to build modern mobile and web applications and in turn, all of them are turning into technology companies.

Now, at the heart of these like new customer experiences are software developers who are having to build these custom web mobile applications. And we're really excited about this movement and being a part of that. And so, as we're trying to deliver the best products we can, as we're trying to deliver the best experiences and we're trying to be the best partners to these companies who are going through these evolutions, we're really focusing on making sure that the developers are successful. Like giving them the tools and the product that they need.

It's this commitment on the developer, and the customer experience, and the customer identities that's driving increasingly large investment from us in our developer products and our customer experience products.

And so earlier this year, we acquired a company called Stormpath and it's-

Audience:  Whoo!

Alex Salazar:  Whoo! Thank you. And Stormpath is really the largest acquisition we've ever made at Okta and it's important because Stormpath was an identity company really focused on giving developers what they need to build applications, to help them move faster, to help them reduce their development cost and also to help them improve their security posture in their applications.

And the core innovation of Stormpath was really our focus on developer experience, making it easy for the developers and also, building a unique go-to market model to reach developers as part of the business.

Now, we're taking all of that expertise and all of that DNA and we're injecting it into Okta to really accelerate our developer products and making sure that we win this market. And we're really excited about this market as we think it's huge and the way we think about it is when you look at something like Stripe and what they're doing for payments, and when you look at what Twilio do for communication, that's what Okta is for identity. And the really exciting thing is that every application needs identity.

As Claire mentioned, I'm Alex. I'm a former CEO of Stormpath and I'm one of the VPs of Products here and in addition to a number of people in this room, I'm responsible for developer products. 

And so what we're gonna talk about today is our roadmap. Everything where we're working towards, where we're taking the products in the near term and in the future, and so first we're gonna talk about what we delivered at the last Oktane. Then we're gonna talk about what was announced here at Oktane and then from there, we're gonna talk about what we're thinking about delivering over the next 12 months. And then we'll talk about how we're thinking about the business kind of the guideposts of everything we're gonna do beyond the next 12 months.

Now, important point from our lawyers, everything we're gonna talk about is roadmap and the big part of roadmap is that everything we're gonna talk about is gonna be forward-looking. It's gonna be things that we are planning on delivering and we're doing our best to give you a clear view into what we're planning on building but as with any roadmap, everything we're gonna talk about is subject to change. 

So please understand that as we walk through this. And my goal, my hope is that as we talk through all the things that we've announced, all the things we've built and all the things that are coming, that you get excited as we are about these product segments. And if you're an existing product, my hope is that you will evaluate all of our new feature sets and find better ways of working with our developer products and expanding your adoption. And if you're not yet a customer, my hope is that you'll try out the products. You'll talk to our sales teams. I hope to learn more about how we can partner with you and help your products to be successful.

So first, what are our API products? Our API products at the end of the day, they're really our core Okta products. It's the things that your IT departments are probably already buying for the employee use cases. It's things like the universal directory, our lifecycle management, multi-factor authentication and API access management.

The innovation here is that we've taken all of our core products and we're exposing that underlying service layer, the technology that makes them all run or exposing those APIs back to you so that your developers can build on top of them. And what that means for a development team is that what they're gonna get as a result of all of this is out-of-the-box user management for their application, out-of-the-box modern authentication and modern authorization for things like APIs.

Now, since the last Oktane, we've been very busy but even before the Stormpath acquisition, Okta was already making a very big investment in developer experience, and they delivered a lot. So one of the first things that we can talk about here are our sample applications. We built a lot of sample applications and a lot of code generators. And the goal there was really to help developers bootstrap their first application. 

"Oh, I'm building this kind of application." Well, here's a sample application that shows you how to do that, right? Taking a lot of the guesswork out of the developer and really trying to minimize the amount of code they have to figure out. In addition, we made a big investment in documentation, really greatly expanding our reference documentation.

It's my firm belief and our firm belief as an organization that documentation for developers is more important than the actual features, right? If a feature isn't well documented and it's not easy for the developer to implement it and get it working in their application, it might as well not exist.

And so we made a big investment and the reference documentation's excellent. In addition, we've also built out a developer forum. This is important because developers like to self-service. They don't wanna have to pick up the phone to understand how something works. They wanna go to a website, ask a question or find a question that's already been answered, kind of like a Stack Overflow.

And by us building our own developer forum, we're really enabling those developers to self-service. When a developer does ask a new question and we answer it, that answer is now permanently documented on the web. And so when another developer comes in with the same question, they can find that answer. And the really exciting thing is as our community continues to expand, not only are we answering many of the questions, we're trying to have our own developers and other companies or community answer each other's questions. So we're really excited about that.

We also released delegated administration. And this is really important for things like help desk. If you are building a customer-facing application whether it's web or mobile, there's a high probability that you're gonna start having customers engaging with support, right? They may pick up the phone and call the help desk or maybe they're opening tickets.

And when help desk goes to help that customer and help desk needs to go potentially administer some user data, you don't necessarily want your help desk administrator to have to login to a full-blown version of Okta and have full access rights to all the data. You want that help desk administrator to have access to only the things they should have access to.

And so by delivering delegate administration for help desk, we allow you to scope down access to Okta for what the developer assuming [inaudible 00:06:58] for what the help desk people need.

The other thing that we did and we're really excited about is that we deployed a new product. If you were here last Oktane, we talked a lot about API access management. That product is now out and that product is awesome and we're really excited about it.

So what this means is everybody's building APIs and you guys are building APIs for a variety of things. If you're building a mobile application, that mobile application can only work if it's talking to server-side APIs that you're building for it to get data and kickoffs were close.

If you're building a modern JavaScript application with React or Angular, it can only work if it's talking to your back-end APIs that your building. If you have an IoT strategy, your devices can only do their jobs if they're talking to the APIs that your building on the backend. And if your IT organization is building up microservices to modernize their service layer, those micro services can only function if they're talking to each other via API.

The problem with APIs is that a lot of developers don't really know how to secure them properly. And if you go online, you'll find a lot of things about how to secure APIs and not all of it's comprehensive. So a big one is well, let's throw [OAuth  00:08:02] on top of an API and that's the right answer. OAuth is the way that we build and deliver our API security layer.

The challenge is that a lot of developers will look for code on Stack Overflow and copy and paste. It's a really bad idea or maybe they'll go find a library on GitHub that somebody else built that adheres to the OAuth spec, that's a bit better but many of those libraries aren't that well maintained. It's two guys and a dog who wrote it and you're lucky if you get a GitHub response to an issue in two weeks.

But the even if you find a great library that's maintained by a big company like Microsoft, the other challenge is that simply adhering to something like OAuth to secure API isn't enough the OAuth spec while great, doesn't cover a lot of security best practices. And I'll give you one really good example. It's token revocation.

If you've got an API and you've got an end user who's using one of these more modern mobile applications that's backed by your APIs, if that user's malicious or delinquent, you have no way of revoking that token while their token is still unexpired. And so if you wanna turn that person off live, you have to go through custom R&D to build out your own revocation scheme. Most developers don't even know this is a problem and you won't discover it until it happens live in production.

With the vendor like Okta, all of this out of the box. Your developers don't have to worry about it. They layer us in and all works and not only do they get OAuth as a service, which is what the developer wants, behind the developer your IT organization, security organization can come back after the application's built and layer on access policies without having to have the developers even understand how this stuff works or care about them.

We're really excited and this product has tremendous traction. So we're all in on this product and we have more announcements coming. But let's talk about what this really means. So for those of you who aren't deep in APIs, let me give you an example. So we've got a customer who's of solar retailer. Now, you may have seen this during Eric [Berg's 00:09:50] session yesterday but if you haven't, I'll walk through this again.

So the solar retailer wants to build a mobile application for their door-to-door salespeople, so that the salesperson can look up information for their customers, maybe put orders in while they're in the field. In order for that mobile application to work, the solar retailer has to build APIs that front the CRM so the mobile app can work.

They get that working. They wanna make sure that's secure. They wanna make sure that the salesperson who is accessing that mobile application can only access the customer data that reflects his customer base. You don't want him accessing all the CRM data. You want him only accessing things that are relevant to him. So you need access policies in addition to a security layer.

In addition, that same solar retailer wants to build a mobile application for their customers. So customers can see usage reports and see how they're doing. That's great. Well, same thing. Now that they build this mobile application that's interacting not just with the CRM data but also with the usage data and all of this needs to be exposed via APIs. 

And just like the salesperson example, you wanna make sure that that end user only has access to their data, not their neighbor's data, not somebody else's data. Again, same thing. So we put in that service layer automating and securing this experience. So that's what we built it to last Oktane.

For this Oktane, we've delivered a lot. So buckle up. There's a lot of categories of things that we're announcing. The first one is really our major expansion and improvement over the developer experience. A lot of this is being driven but Stormpath acquisition and that injection of developer DNA.

The other one is really a focus on enabling you as the customer to really put your brand and the customer experience that you're trying to drive for forward. And so the customers see your brand and not ours. That they see the customer experiences that you want them to have, not the customer experiences that we're dictating. And then next from there is out-of-the-box workflows.

This is a bit of a nuance point. Developers today can build whatever they want on the Okta APIs, right? If they wanna build some really amazing custom workflow, they can do whatever they want on top of the underlying APIs. They can assemble it any way they want but the problem is there's still a lot of code associated with this. So we're focusing a lot on delivering [inaudible 00:12:12] workflows to take something that might have taken a developer a few weeks or a few months to deliver and turning it into 15 minutes or a few days of configuration and customization.

And in addition, we're also focusing on delivering better security around authentication. We have a lot of great security technology that we're redelivering as part of our core products. How do we expose the underlying security authentication technology to the developers so that they can deliver a higher level of security in their application that is on par with what we're doing for our own customers?

And then last as you saw earlier, we're betting big on API access management. So we'll talk about an important announcement we're making for that feature. So let's talk about developer experience. Developer experience means a lot of things to a lot of people but for us, it really means how do we drive developer love. How do we get the developer to not only be really productive and deliver applications faster but also, how do we get them to enjoy the experience?

And this isn't just about having people like us. This is actually really important because developers tend to follow the path of least resistance. They will build it themselves if it's faster and easier than an alternative. And while that's great for their sprint cycles, it can sometimes create situations where they've cut corners on security because maybe they didn't know or it was just faster.

And so it's our belief that the better the developer experience, the easier we make it for the developers, the more likely they are to use our path as the path of least resistance to deliver a better customer experience that's also more secure than what you might do otherwise.

So what are we done in developer experience? The first thing we've done is we've released a new packaging of our API products. We call this the developer edition. This is a stripped-down version of our API products that many of you are already purchasing and it's really designed for developers to self-service.

Again, developers love to self-service and so if they need a small version of Okta to build a modern mobile or JavaScript application, and it's for a small project or maybe it's for them to initiate a proof-of-concept or an evaluation of the product, they can very quickly sign up for the service, start playing with it.

And the moment they need some advanced technology as part of this package, they can swipe a credit card and self-service into it into a paid tier. Not only is this really powerful to help drive developer experience, and make sure developers can self-service but it's also critical for Okta because it's our first foray into delivering our products through eCommerce.

The other major improvement we're making is around onboarding. Onboarding is really important, again, because developers are impatient. They're really busy, right? They're really busy. They're really expensive and chances are you don't have enough of them. And so we wanna make sure they're very productive and so by helping them onboard onto our product by helping them get that quick win, by helping them get enterprise-grade authentication happening in minutes or instead of days or months, we're focused on really giving them a great onboarding experience.

And that onboarding experience is gonna start with the user experience, what they get when they log into the dashboard. Historically, when a developer logs into Okta, they get an IT admin experience. That user experience is really around managing third-party applications and managing employee access.

And so it's a bit of a paradigm shift for the developer to try and wrap their heads around that model. So what we've done instead is we built out a developer dashboard. It's all the same product but now we're packaging it up differently, displaying it differently so the developer sees what he needs in the context that he needs it for building a modern application and managing customers or employees that are accessing those custom-built applications.

Another part of our onboarding experience is renovating our developer site. So if you've ever been to developer.okta.com, you'll see a major change in how that site's laid out and how we talk about the product. And so we've really redesigned it to talk to developers in the way that they like to talk about this in their language. And making it very quick and easy for them to understand what these products are, where they fit in their architectures and giving them quick access to all the resources they need to evaluate if Okta is the right solution for them.

From here, they can sign up for the product in a self-service fashion and then dive into the dashboard and our documentation. And then I think probably one the most exciting part of our onboarding is that we have now built out what we refer to as app creation wizards. 

And so instead of a developer having do some guesswork as to how to use our service to implement different kinds of applications, when he goes to create an application, we're simply gonna ask them, "What kind of app are you building? Are you building a native iOS application? Are you building a traditional Java-based web application? Whatever kind of application you're building, tell us. You click on the right one and then from there, we give you very specific step-by-step instructions to take all the guesswork out of it. And get you from having no identity in your application, to having enterprise-grade identity in minutes."

Documentation, you always hear us talk about documentation. For the next few years, when I get up on stage and tell you all the great things [inaudible 00:17:08] developer experience, I can promise you documentation will be on the slides. So we're expanding our documentation beyond the work that was already done.

So today, we've got great reference documentation. That means that when a developer wants to know how an API endpoint works, they can quick look in the reference documentation and go, "Oh, okay." They can find the API endpoint and say, "Oh, it works like this." but that's great for the more advanced developer.

Other developers maybe don't wanna go to that depth. They don't want to have to go to that level of understanding because they just wanna get multi-factor authentication working. And so we're now releasing what we referred to as task-oriented documentation. So if the developer's question is instead, "Hey, how do I implement multi-factor in my mobile application?" They can go to the documentation and just have step-by-step instructions. It just tells them how to do it without them having them to dig into the internals of how we work.

And if the advanced developer really does wanna get to the internals, they can always drop back down to the reference documentation. In addition to the task-oriented documentation, we're also rolling out quick starts. This is, again, really important for the developer who just wants to go off the ground in 15 minutes and just get something working.

But the heart of our developer experience is our SDKs. So we've always had SDKs but we've been greatly renovating them since the Stormpath acquisition. And what we're doing is we're really making our SDKs take care of a lot of the heavy lifting the developer typically has to do.

At the end of day, we're trying to take code out of their custom application and putting it back on us. And so the first step is providing great language-based SDKs, Java SDKs, C# SDKs, iOS SDKs. From there over the next few weeks in a few months, you'll start to see us rollout what we refer to as framework plugins.

Most modern applications are being built using frameworks that automate a lot of what a developer [inaudible 00:18:54] do to build a modern web or a modern mobile application. And so we wanna plug into those frameworks and just walk across all the existing patterns that are already in that framework.

And what that means in English is that instead of a developer taking a sprint or two sprints or three sprints, a few weeks or a few months to wire in an identity service into their modern application, they instead do NPM install Okta Express. And in five minutes, they've got a fully functional enterprise-grade authentication user management system up and running. And then all they have to do is a few hours or a few days of customization to make it look the way they want it to look.

And then from there, our goal beyond that is to then elevate that and expand our AP Access Management story to then start hooking into things like API gateways. You know, things like Amazon API gateway, things like Nginx, things like Apogee, things like Milsoft, things like [Kong 00:19:45]. 

So customization in branding. In a customer-facing application, what the customer sees and the experience they have with your application is a critical part of your customer-facing application. And especially if it's a consumer-facing application, consumers are very impatient. If that experience isn't up to par, they might bounce and never come back.

And so we're really focusing on delivering better tooling to give you the experiences you want. So the first thing we're doing is we're improving the capabilities of our out-of-the-box login screens. So again, let's go back to what a developer could already do. A developer can already build whatever login screen he wants by hooking into our underlying APIs and delivering a unique experience that's completely bespoke, completely custom.

But we wanna make it easier for developers. So what we did, a few years ago, is we developed a widget. There's a little JavaScript component that a developer could drop into his HTML and have a lot of the security logic just work. And then all the developer and the organization had to worry about was customizing that screen, making it look the right way and then deploying it onto their servers and running it in production.

That's still too much work in our eyes. So we are now announcing the fact that we can pre-host. Okta can host these screens for you. So all the developer has to do is just customize the screen. We take care of all the operations work. We take care of all the deployment work. We take care of all the security work around managing security screens.

And all they have to do is drop, and copy and paste their custom HTML code into our dashboard, hit save and it's up and running.

As part of that as well, when someone lands on one of these hosted login screens, you don't want them to see an Okta URL. I mean don't get me wrong, the Okta URL is amazing and it's gonna indicate to your customers that your application is very secure but not every end-user knows what Okta is, right? If you're building the next snapshot. A 19-year-old may not know about the latest and greatest security company.

And so you want them to see your URL. It's not just because of your brand, it's also about trust. If they see your URL that's not yours, they might think it's a phishing attack, right? And so we wanna allow you to put in your own URLs through what we refer to as vanity domains or custom URL domains.

Same thing goes for emails. If you're using one of our pre-built workflows like password reset, you want those password reset emails to have your email domain not ours. So the customer knows who it's coming from, so they can trust this. So they're confident it's not a phishing attack.

Our out-of-the-books workflows are really important. It's accelerating speed to market for applications and make it easier for developers to deliver secure experiences. So we're expanding the workflows that we support. Now, because of our commitment to customer experiences, in addition to employee experiences for our core products, we're focusing on that branding we just talked about but we're now also expanding our workflows to include self-registration.

For any consumer-based application, self registration's a standard and increasingly, for B2B applications, you're starting to see that as well. We now support self-registration as an out-of-the-box workflow. Your developers can just drop in to their application with either the APIs, dropping in the JavaScript component into their HTML or using one of our pre-hosted screens.

And the power of this is that not only do we make it easier for the developer to have one of these flows, we're also minimizing the amount of code they have to write. So instead of them having to write all this custom code to manage how the rest of the screens work and determining if they wanna kick off activation flows with an email, they can just point and click, configure how this works. It's fantastic. It really is gonna make their lives a lot easier.

Oh, and also as part of this, we're also expanding how we make our existing workflows work. So instead of a developer having to use one of our pre canned workflows and being stuck to a very rigid set of steps, they can step out of the flows, like a password reset flow, run their own logic in their own code over here and then call APIs to step back into that flow.

That makes the developer happy because now they can deliver that that custom experience that's in the requirements document while still using our pre-built flows and have them custom built everything. 

Now, security is big. I mean at the end of the day what we're really trying to do here is we're trying to help you and your developers deliver secure customer experiences and a big piece of that is that we are already security experts and we're already delivering best-in-class security for all of our products. 

And not only do we want you guys to use that in our IT products, we actually want you to have that same experience in your custom applications. We want you to feel like a modern technology company and a modern security company as you're building your applications.

And so to do that, a big part of it is multi-factor authentication. As the threat level in public applications, which just continues to go up, we're trying to see more and more multi-factor become a standard in modern applications. Even on my Facebook mobile application, I've got MFA turned on. It's a common pattern that's becoming more and more common.

Now here's the thing, there are a lot of different factors out there and we support all of them. So if you've got security questions or passwords, that's the standard. Everybody's got that. That's the lowest level of assurance and it's also the easiest. Everybody knows how to use a password. Everybody knows how that answer security question but if you need a higher level of assurance then you start moving up along this path, and you start moving to SMS messages or one-time passwords.

And if you want a higher level of assurance than that, then you start moving into hard tokens or push this to a mobile application like the way Facebook works at our mobile application. If you want a higher level of assurance than that, you start going to biometrics either on the back of your phone or with another device.

The problem with all of these is that as you go up in security, it's typically harder and harder for the customer. It's harder for them to understand. It's hard for them to adopt. And adoption is a really big problem in MFA, especially when you're talking about customer-facing applications.

And so that's why we're announcing email as a factor. Now to be honest, email is not exactly the most secure form of authentication but the real trick to the real beauty of email as a factor is that it's ubiquitous. Everybody understands how to click a link in an email. Everybody has an email address. Everybody can access email from their phones or their computer.

And so for some applications where security really matters, we've a really broad base of customers, like retail banking or healthcare or government. If you wanna provide a more secure experience than just a password but you wanna ensure that it gets widely adopted and used, email as a factor becomes a good option. And perhaps it's in addition to other forms of authentication.

So this is powerful for a lot of our customers. We hope you explore it but if you need a higher level of assurance, we also have all the other factors we talked about earlier.

Now, the problem is that the password is still king. Every application should support password. And while passwords suck, we're trying to make it easier for you. We're trying to make them suck a little bit less. And so we've been doing a lot over the years and so one of the things we already do is we help you drive password complexity. You wanna make sure there's a capital letter, a lowercase letter, a number and maybe a special symbol. We can enforce and support that for you.

But even then customers can still get around that. They can type password123 with an exclamation point and still have a password that meets your requirements but that's the password that's easily guessed. And so if you've got a malicious attacker who wants to start brute-forcing users, they can type in password123! and have a high probability of hitting one of your users into getting all the way in.

And so part of what we're doing is we're gonna be rolling out common password detection to really protect your end users from themselves. If you want to turn this on, it's optional. So if you need a higher level of assurance, turn this on and it automatically works.

So in addition to security, we're also expanding our API access management product. Again, this product's already out. It's already got tremendous traction. Now we're just expanding what it can do.

So let's go back to that solar retailer we talked about, that's building mobile applications for their salespeople and their customers. This is great. They're really happy but now with their success, an energy utility decides that they wanna partner with them. And the energy utility wants to build their own mobile application. That is not only providing the end-user all their utility statements but maybe they wanna also show or consume some of that solar data that the solar retailer has.

In order to do that, that electric utility has to talk to the solar retailers' APIs. Their users' API are potentially there CRM. Now a best practice is not just to give that solo retailer full access of the user data, the best practice is to allow the end-user to know that this is happening. And give the end user the option of saying yes or no because it's their privacy data.

And so what's a common pattern here is giving the end user a pop-up screen either in a mobile application or a web application that gives them consent, that says, "You know what, here are the things that PG&E wants to see. Are you comfortable with them seeing this information? Hit yes or no."

And we've all seen this before. If you've ever logged in to Airbnb with Facebook or you've logged into any other kind of application with Facebook, you've seen this screen. We're now enabling all of our customers to support that same thing as Facebook and allow all their partners to access their customer data in a way that ensures that the customers have control over their privacy.

So those are things that we were announcing here at Oktane. Now, there's a lot that's coming down the pipe and so let's talk about the things that we're looking to do in the next 12 months.

The next 12 months, a big focus for us is gonna be around driving extensibility. And what that means is how can we make it easier for developers to wire in more custom logic or other systems into the pre-built flows that we already have to hook into our event systems, to hook into any kind of mutations on data.

And so there's a few things we're gonna do. The first thing we're already doing is that we are committing to open protocols, whether it's OAuth 2, OpenID Connect, SCIM or Fido. We're committed to these. And the open protocols are important because that means if they wanna hook in any other security system, we can communicate on a common protocol very easily, whether it's another type of multi-factor tool or they wanna hook into an existing IDP for SAML. Whatever it is, we can support those if you want a common standard.

But not everything you wanna hook in to Okta is gonna operate on a common standard. And so the next thing we're focusing on is really supporting events, right? Or as we refer to them, asynchronous web hooks. And so as something's happening in the Okta product, we can then kick off events off to other systems, whether it's your own custom code or some other service you're pointing us to this is really important because you might wanna push customer events, changes that are happening or customer activity to your CRM.

You might wanna push things that are happening to your data warehouse for analytics later on or you might wanna create tickets in your service management system, like ServiceNow. We're also building out flow extensibility and what that means for technical people is we're building out synchronous hooks.

And so that means that as one of our pre-built workflows executing like registration of service, we're inserting breakpoints in that registration where that flow stops, calls out to some other logic that you dictate and we wait until that comes back as success before we continue the flow.

All of these are really powerful because it allows for things like progressive migration. As users authenticating, we put a breakpoint, pull in from another system, pulled our data into our databases and now they've been migrated into Okta live without having to go through a forklift migration and all hidden from the end-user.

It also means if you try to do account linking maybe across social information or other information from the IDP, we can put those account links as part of a registration service or authentication service. And if you need higher level of assurance where you wanna make sure the person who's registering is who they say they are, we can put a break point and call out to Experian or some other proofing system. Wait until it's complete and then finish the flow.

So to give you an example of how this would work, I wanna walk you through the registration of the service and our vision for what we can do with accessibility. So a user lands on your registration screen and they initiate registration.

Well, the first thing you're always gonna wanna do is you're gonna wanna kick off an event to Google Analytics. So that Google knows that they've now achieved this milestone. So your marketing team can then continue optimizing and tweaking their onboarding flows or their marketing flows or their funnel flows. That's great. That's an asynchronous hook out to your Google event system.

Now throughout this process as they start to put in their personal information, they hit enter, they then get kicked over in a synchronous flow to Experian for identity proofing to make sure they are who they say they're. And after that flow is complete, there's a callback to the Okta service and we continue towards completion of this registration flow.

And so the user has now put all their information. They proved that they are who they say they are and that process, we're gonna create a synchronous hook out to Salesforce and create that user record and we need to do that synchronously because we don't want to get out of sync, right? We wanna make sure that that push to Salesforce to create that account record is successful before we complete registration.

Now, on an asynchronous side, we're gonna kick off an event to the data warehouse with all the information we collected somewhere else, so that your analytics team can do some follow-on work in the coming months or weeks or years.

And as we complete the registration, once everything's done and the customer gets this success screen and this welcome screen, we might kick off another asynchronous event to your marketing system, to kick off an email nurture flow. So that as they start to experience your product, they're getting all the drip emails you want them to get, so they become a more engaged customer.

Not only is this important for customer identity and not only is this important for flows like registration and authentication, extensibility for us is gonna be a critical piece of how we evolve the entire Okta product set beyond just our API products. This is gonna be big for all our products [inaudible 00:34:00] over the coming years. It's a huge investment, so stay tuned.

Social. If you're building a consumer application, there's a high probability that you need to have a Facebook login screen or you need to have a button that says, "Log in with Google." And increasingly for B2B applications, you're trying to see these two, in particular for things like Google and G Suite.

We support all the major ones. Google and Facebook, which makes up the vast majority of this market but also, LinkedIn and Microsoft. Over the next 12 months, we're gonna add support for Twitter because people still need that. But there's a long list of other social providers that you might need depending on the context of your application, depending on the industry you're working in.

And so while we can't support everything directly and natively, what we can do is we can build a generic OpenID or a generic OAuth integration so that you can self-service and plug anything in that supports the standard protocols.

And that gives you a near limitless list of integrations you can make for any social login and so I'll give you an example. If you're building an application that's gonna be focused on other developers, you might want them to log in with GitHub, right? With this generic integration, you can plug GitHub in or maybe you're building an application that you're focusing on the Chinese market.

Well, you're gonna wanna hook in a Chinese social provider, that's maybe not Google or Facebook and you wanna do that through the standard OpenID or OAuth integration. Or maybe you're a retailer and you wanna let people log in with their Amazon credentials instead of Facebook or Google. Again, you plug them into the generic integration that can all work. We're really excited about this as we expand into customer identity. 

Now again, back to security. We talked about multi-factor authentication and how we can really support a variety of factors to make your application secure and also, allow you to go up and down depending on experience you wanna deliver. But the problem is that developers are increasingly being asked to do more around security than just passwords. Maybe the business units saw how cool the Slack magic link is and they decide that they want that in their application.

And there's this new model coming up that's gaining popularity called Password-less, right? How you authenticate your user without having to have them remember a password. For some applications especially applications that you don't really interact with that often, Password-less is popular but how do you make it secure?

Well, the way you make Password-less secure is you need to create policies that link together any number of these different factors other than the password to not just deliver the user experience you want but also, the security that you need in the application.

And so over the next 12 months, we're gonna be focusing on allowing you to create these secure policies to deliver a good secure Password-less experience, not just a quick link to email to make it work. Okay, so that's what's happening in the next 12 months. Let's talk about we're thinking about beyond the next 12 months.

Now, I'm gonna talk about at a higher level because these are really goal posts for us. These are really the kind of the guiding lights as we think about the future of not just developer but also, customer.

So the way we're thinking about it is first around customer experiences. Most of these custom applications that developers are building are customer-facing applications. And so as we think about how do we improve, how do we help developers and their organizations improve on the customer experiences they're developing? We're thinking about things like progressive profiling.

When a user self-registers instead of putting a registration screen that's got 15 different fields on it, and increasing the risk of that consumer or that business user from just giving up and bouncing out, how do we make it so you can just ask for something really basic like a phone number and email address?

And then over that user's life cycle in your application, slowly and steadily start prompting them for more information. So you still get those 15 fields but instead of getting them all in one shot and risking the user experience, maybe you get it over the course of a few days or a few weeks or a few months but ensuring that the customer sells a good experience.

Another important piece that we're thinking about is impersonation. If you're building a customer-facing application, again, chances are, they're gonna call your help desk because they're ultimate gonna have some sort of issue in the application. And we wanna make that support experience a little bit better.

So instead of the support agent trying to really understand what's happening and trying to think about how to recreate that experience in a different context, functionality like impersonation where the help desk admin can log into the application as if they are that user is important because then it can ensure for the higher likelihood that they can see that bug, that error, that missing data, that incorrect data in the way that the customer is experiencing. And take that guesswork out and help this experience smoother and cleaner for the end-user.

Developers are focusing around developer agility. When we talk about customer experience, we're not just talking about developer love. We're also talking about developers, what they deliver, where you're asking them to deliver much faster. 

And so as we think about developer agility, there's a few things we're thinking about. One of them is bringing your own directory to Okta. That's important because you might already have a database or some other system that has user data in it and you might not wanna migrate that to Okta.

There might be a number of other systems that are already hooked into that database. You need to preserve that system. How do we allow you to hook into that while still experiencing all the value that we're building across the Okta platform above and beyond just our directory product?

Also, around mobile support, mobile is big. Everybody is moving more and more towards mobile applications. The problem with mobile application development is not just that it's hard, and it's not just that there are all these security patterns that are difficult for developers.

The thing that's really hard about it is there's just aren't enough developers that have experience in mobile application development. If any of you have tried to hire an Android developer who has experience that's any good, it's hard. It's very difficult. In some regions, nearly impossible.

And so we're trying to lower that bar for you to not just deliver a great customer experience but also, secure experience in mobile by seeing how much more mobile tooling can we get. So maybe a more junior mobile developer or maybe a non-mobile developer can still deliver that great experience with less work.

And also as we focus on giving developers what they need, we also need to be really cognizant of what's happening in the developer community. A lot of innovation is happening in the developer community, and they're really consistently pushing the envelope. And some of the big trends turn into standards, and some of them ultimately fall by the wayside.

We're trying to make sure that we're part of all of it so that we're an early supporter of new patterns and new paradigms. One that we're looking at actively is this notion of functions as a service. And so I don't know how much you know about this. If you are around later today, there's a session on this with Amazon and our team but as developers start thinking about new ways of building applications beyond just building monolithic applications in Java or Ruby or Python, we're trying to see how can we be a better partner as they move to things that functions as a service.

And then back to security, at the end of the day, what we're trying to do with everything we're doing is how do we let developers deliver the best security by default, even if they don't know anything about security because most developers don't.

How do we make it really easy for them to deliver best-in-class security? Because it's the easiest thing to do. And so there's a lot of things we're thinking about and it's not just about security, it's also about privacy. Because in customer-facing applications, that's an increasing set of requirements both in the U.S. and internationally.

So around security, we're trying to take a lot of the advancements we're making in our core products around adaptive behavioral security, where we're looking at more than just passwords or looking at their activity. We're looking at their IP addresses. We're looking at a broader pattern of what's happening in the application and what's happening with that user to detect where there might be a higher risk end-user.

How do we expose all of that awesome logic to the developer so they can have that same functionality in your applications. So that you can then determine if you wanted to step up, or maybe you wanna block somebody, or you wanna do some other workflow to secure your application.

On the privacy side, how do we help you deliver the privacy experiences that you're increasingly being required to deliver? In places like Europe, now these are becoming laws and so how do we give you the workflows to drive consent and privacy flows that make your customers secure and private while adhering to local regulation?

And then one of the things that's made us really successful and hopefully, you've heard a lot about it over the course of the day is our commitment to partnering. In our core IT product segment, all the products that have made us successful, that's gotten us to where we are, we have built an enormous ecosystem of partners, over 5,000 partner integrations to do a variety of things for IT employee-based workflows.

How do we extend that success into customer identity and developer products? And we're starting to think about that a lot and so there's a few things we're thinking about. How do we partner up with CRM vendors so that our registration flows, all of our activity flows automatically hook into the CRM and start funneling that information to your single pane of what's happening at field level, at a marketing level, at a sales level with the end users that are in your application?

Same thing with marketing analytics, how do we push all these events to those systems so that your teams can quickly run whatever reports they want and have those reports be informed by the data that we're seeing and we're collecting?

And also if you've ever done any work with payments, payment and subscription information and those systems like Stripe and Braintree and PayPal, they are tightly linked to the users identity. So how do we make that integration seamless so that your developers want the monkey patch code to make Stripe work with identity system?

And then lastly, for applications that need that higher level of assurance of who the user is, how do we better partner with proofing solutions like Experian and others to make sure that when you're building out your registration flows or any other kind of flow, you can easily hook in one of these partners and just have it automatically work, minimizing the integration work your developers or systems integrators have to do?

So these are the things we've built. These are things that we're planning on delivering. We're really excited. Hopefully, you guys are excited as well and so my ask is that if you are excited, that you learn more. And there's a lot of resources here.

So one we had the new developer site. So if you are interested in learning more about API products, I ask you to please come to our developer page, learn more about it, sign up for the service, play around, build an application, see how easy it is. Also, if it's not that easy, give us feedback. We'll make it easier.

We're also making a big investment in developer relations. We have a great developer relations team. They're generating a lot of high-quality content to really build thought leadership and awareness in the developer community. Follow us. We're very active on Twitter and this is all brand new. So you guys can get on the ground floor early. And if you guys do have a project and you're interested in how we can help you, contact sales. Contact our salespeople. Contact our support people. Contact us at info@okta and engage us and let us show you how great of a partner we can be.

And so with that, before I open up the questions, I wanna recommend a few sessions. So if you like what we're building and you wanna learn a lot more while you're still here at Oktane, there's three sessions I'll recommend. The first is really around how to build restful APIs in the right way. That's gonna be presented by my co-founder from Stormpath, Les Hazlewood I think immediately after me. That's awesome. I recommend that session if your technical.

Also, if you wanna learn more about how to build APIs and secure APIs, and if you wanna learn a little bit more about functions as a service, there's gonna be a session later on with Amazon. That's gonna be hosted by somebody from Okta and somebody from Amazon talking about these modern architectures around APIs.

And if you are a developer and you really wanna get into the code and really see how we can build an application together, how we can take a spring boot back-end and wire it up with APIs, and deliver an angular front end, we're gonna have a session at the end by Matt Raible who is one of our developer evangelist and very popular in Java community.

So with that, I hope you attend more and we'll take the minutes that are left and answer any questions.

Claire:  Questions? All right.

Alex Salazar:  Never mind, no questions. If you have any questions ... Oh, there's one. We're gonna get one one before we get the hook.

Speaker 3:  Yeah, for the new developer experience, is that only if they sign up for their own developer instance? Or is there a way of bringing that for existing organizations instances?

Alex Salazar:  Yeah, that's a great question. So the question was, is developer experience exclusive to the new developer orgs or can we turn that on for any existing auth implementation?

The answer is you can turn it on for any existing auth applications. So again, the beautiful secret of what we're talking about when we talk about our API products is that they are basically the Okta products. So if you've already got an auth implementation and you wanna write some custom code against it, all of our SDKs, all of our documentation, all of our libraries, all of that goodness will perfectly work.

All of it will work. Now, if you want the developer dashboard, if you want that native visual experience for developers, my recommendation is contact support and what they'll do is ought to turn on what's called the feature flag. And when they turn that on, you'll get that new dashboard.

Claire:  Other questions?

Speaker 4:  [inaudible 00:47:41] future flags.

Claire:  Oh, there are many future flags but for the developer experience that's probably the one that I can recommend. Yeah, the reason we haven't turned it on for all the orgs is that we don't wanna suddenly brute force everybody into new experience and ruin their day as they're trying to do some work.

Speaker 5:  Hi, yeah-

Claire:  By the way, last question because we're getting the hook.

Speaker 5:  Okay, yeah. Sorry, really quick. So we have a situation where this is more of like a kind of road map/API question but we have preview instances and we demo a lot of stuff and make sure that we have everything tuned up and yep this looks good. And then we have to go replicate everything over in our prod instance. Do you guys have any sort of plans for either migrating configuration over or exporting configurations something like that?

Claire:  That's a great question. The question was how do I [inaudible 00:48:21] for my dev instance and my production instance and minimize my work? Yeah, we're thinking about it. We're absolutely thinking about it. You're not the only customer that's having this problem.

I don't yet have an answer for you, so my strong recommendation is if you know you're gonna be using Okta or you're high-probability gonna use Okta, my recommendation is you work with your account team to set up a dev organization in the production cell. So that once you get your POC working, that can turn into your production instance. And then you can keep a separate sandbox for any work you're doing on an ongoing basis to make sure your code's working.

Cool, awesome. Well, thank you everybody for your attendance. If you have any questions, you wanna talk to me afterwards, I'll be right outside.

Claire:  Whoo!