The New Developer Experience at Okta

 Thanks, Steve. We’re really excited to be here, and really excited about the partnership. You know, at Okta, in the past 6-8 months, we’ve talked a lot about the importance of developers and developers have become massively important. You know, they’re massively important influencers in all parts of an organization, and are integral to the success of today’s businesses. Regardless of you know, what industry or vertical you’re in. Developers are instrumental to building new applications and experiences and driving innovation.

 They might not always be the ones holding the budget but their opinions increasingly matter. And at Okta, we want to do everything we can to engage with them and create great developer experiences when they’re using our technology. But you know, as most of you joining like, you know, that there’s a lot on the plates of developers today. And, you know, they’re being asked to solve more and more complex problems for businesses and customers. And they’re asked to do that quickly. And this is really why we’ve reimagined the Okta developer platform, and the Okta developer experience, to speed time to production across the application developer lifecycle, and across the entire developer tool chain.

 We’ve launched new open source tooling and tighter integrations with app generators, like J hipster, platforms like Heroku, and API gateways like Kong, so that every step of the journey can be done faster and at scale. This is including our, you know, automation work that we’re doing with JFrog. Our goal is to meet developers where they are, instead of having them learn all the nuances of identity first, and then discover how often can help. We want to help from the get go. We also want to make sure developers have the help they need when they get stuck, so we’ve enhanced our dedicated developer support and community with experts in the most popular languages and frameworks so that they can get answers when and how they need them.

 Over all these innovations will significantly improve our developer experience As you all know, any innovation or solution that developers are creating has to be done knowing that the underlying technology is secure. This means that a lot is being asked of devs today, new business requirements, new attack vectors, the latest technology innovations all fall on their shoulders to understand and implement. And there’s like millions of signals coming in that are you know, risk. And to do that, and understand what’s happening with all these threat signals and suspicious actors and all that is something that’s really hard to do when you’re doing that on your own. So we’re working to make this easier.

 Developers need automation across the across the application development lifecycle. And in terms of DevOps and CI\CD for auth, this is particularly true for deployment.

 We’ve recently announced updated terraform providers supported by product and engineering so developers can push configuration across Okta Dev, test and production tenants to support automation of CI\CD pipelines. We also want to ensure that organizations can seamlessly control access to cloud native deployments with a single pane of glass for apps, APIs, and infrastructure.

 To that end, this year, we’re also bringing together our CIAM capabilities or customer identity access management, for that seamless experience for organizations that are moving increasingly towards infrastructure as code. And, you know, us being here at SwampUP, we really want to highlight that, you know, really great partnership with JFrog and we’re building on actually augmenting some of the capabilities that Okta can’t do without JFrog and JFrog, you know, can’t do without us. So, in terms of auth, both auth N and auth Z. So, you know, really complex or highlighted kind of authentication and authorization use cases. And so we are integrating with JFrog for the CI\CD and the DevOps side. And we’re integrating with Kong for the API security side and in the future, we’re going to go towards more cloud native and Kubernetes, as well. So look forward to some of that stuff in the coming months.

 As I always say, we at Okta are here to help you secure your apps, APIs and infrastructure, so that you can focus on innovating and growing your business. Now, I’ll turn it over to Jeff, who will show you how all the pieces come together.

 Thanks Bharat, and just to reiterate, we’re really focusing on the developer during this entire process, and really looking at how we can take advantage of all the developer journey steps that you go through in trying to deploy and manage your apps.

 We started auth by announcing, in April, a new fully feature starter Developer Edition with 15,000 monthly active users for free with the intention of allowing you to get up and get running and allow your apps to mature without having to worry about cost.

 In conjunction with that, we’re reimagining the way that our samples can help educate you in the ways that you can use Okta effectively and see how the different features that Okta provides can be useful in your application workflows. We also want to enhance our documentation to sort of explain some of the deep level concepts that you need to understand for apps for auth to make the right decisions for your apps. And then also, as you mentioned, integrating with developer tools that will make this journey a lot faster. And then going beyond that focusing on maturity as your apps need to mature and change.

 Using powerful infrastructure as code and configuration as a code like tools like terraform, that are now in early access to be used to manage all of these configurations. And this is just talk. But let’s take a look and see this actually in action. So I want to start out with a trivial example, right? Like, we need to build an app, we’ve got this idea that we can build this online snack menu. And we want to get this up and running really quickly.

 Well, the first thing we need to do is to create a scaffolding for this, how are we going to get to market in the quickest way possible?

 Well we can utilize a rapid development tool like j hipster, where we’re going to actually create our app based on the standards that we deem are necessary.

 One of the great things about this tool is it allows you to fill out a questionnaire of all the boilerplate needs that you will have for your application.

 If you look really quickly, as we establish how we want the app to connect, we’ve created an an OIDC app. This is just the standard for consumer based apps that are out there, but you notice that there is a plug in there for Okta and another solution like Kiko, you can also select the form of the front end that you like have any JavaScript flavor you want react, maybe angular or view. And then you’re filling out everything you want to see how this app will be created.

 Now, what’s important here is if you’re looking at saying that I want all of my apps to have a particular set, I want them to have an admin interface, I want them to be configured in a certain way. J hipster represents a toolkit that allow you to make sure that all the apps are deployed the same way.

 This allows you to seamlessly transition between developers working on one app versus another because they’re all coming from the same stack and even those variations can be minimized and those create a lot of headaches when you’re trying to manage all of the apps that you may have in a product suite. Now what we’re actually going to do here is completely build this whole thing out and launch a local version of our application. As you see here, we’re finishing up and we should have our app finally built as you see, it’s going to start up here and finish. And we should have our j hipster app running now.

 What we need to do now is actually deploy this. So we’re going to take a look at how we can deploy with Heroku and get this up into some production like state, maybe, maybe Dev, but online, so we can see how this will actually run.

 What’s interesting here is that you’ve got a plugin between j hipster, Heroku and Okta. Before when you were doing this, as everybody knows, auth became one of these big heavyweight stories that we had to deal with. How are we going to log the users in? From my experience in product, we kind of defer this the last responsible moment, so we didn’t really have to worry about it. But as you see here, I’m taking my credential that was created once I started the J hipster app, I’m logging in. And I’m also provisioning an Okta add on. So what you’re seeing here is Okta, J hipster, and Heroku putting all of the pieces together to have Okta configured at the time that we’re ready to launch. And what is also important here, as I’m letting this natural CI\CD process run in real time, is to go over a lot of the decisions that you have to make.

 To step back here platforms as a service, things like Heroku, things like the JFrog pipelines. Also things like Cloud Foundry have done a really good job at us deploying our software, have done a really good job at figuring out how we can deploy our software across the standards that we need to make this effective.

 There are a lot of decisions that go in, I think, a couple to call out is how do I want to get new features out to my customers? Do I want to utilize AB testing? Do I want to have a protected route that only certain customers get routed to? Do I want to have a seamless cutover where I’m pushing features out in a bluegreen method? How do I want to deal with some of these changes that take place? How do I want approvals to work? How do I know that a developer is not pushing code outside of the approval of a product manager? All of these are very important questions. And that’s not even to mention how we ensure that the functionality of the code is there, things like running smoke tests, running pre and post validation tests, just to make sure that everything is getting into the hands of your customers safely and successfully.

 These are all of the decisions that require a lot of the planning from the operations side and from the DevOps engineers to make sure that the sites stay up that they stay active and that they stay safe. And what we don’t want to do is we don’t want to interject auth as a disrupter in that process. So what we’ve done here is we’ve tried to separate that decision that you have to make for auth with the decisions that you have to make for your CI\CD pipelines. And this becomes increasingly effective as you’re looking at how you want to deploy this across multiple apps.

 There’s a difference between doing this for app one and doing this for app in. If we have a bespoke CI\CD pipelines across all of these different applications that we’re deploying, how good is that actually serving the operator community? It means that we actually have to scale out horizontally and that doesn’t really become effective. And again, I really wanted to show that this is happening in real time as we’re completing the CI\CD process, we’re building and compressing all of our artifacts and again, to call out what we see as possibilities in partnering with JFrog is we have to store these artifacts somewhere and we have to retrieve them, there are opportunities for us to do this together, we feel like we’ll have a stronger solution and making sure that these apps are also built, compiled and deployed securely.

 We’ve got just a few seconds left for this to deploy and we should be up and running. I’m actually going to skip over this and we’ll move into what it should look like. So let’s take a look at our deployed application right now. And remember, we’ve actually touched no code in putting authentication into this.

 You saw as I clicked on the sign in button, I’m redirected to Okta, where I can put in my username and password.

 When I click sign in, I’m going to be redirected back to the app. And here we are, we are logged in. Again, I’ve used the rapid prototyping tool j hipster to bootstrap my application with often deploy it. And now I’m able to log in. And this took us just a couple of minutes, mainly spending our time where we needed to on deciding how we want our app to be built, and how we want our app to be deployed.

 Let’s throw one little wrench in this right? I learned early on in my career about the app continuum. And this was a way that I was able to make peace with the concept of models, models had been running my life for a lot of years and I was really kind of concerned on how we would start to break them up because the age old question of how are we going to make this a version two of this large application was always looming in the distance. So what I learned about the app continuum is listening to how your app is being matured and made and start to break it up as things start to make themselves apparent.

 Well, let’s take that through an example. Now where we get a lot of requests from our customers to take our snacks that we’re listing on the site and put them into an API that can be consumed by some of our customers. to maybe use for marketing or to show on their sites as to what’s available. Well, the proposal here is to build a lightweight API and we’re just going to do this really quickly as like, I’m simulating an engineer saying, yeah, I could do this really quickly. Here’s what an API contract may look like.

 When I push it here, there’s one important thing to note that it’s not secured. It’s public and not secure, that may not be the way that we want this deployed. So how are we actually going to build the security in with this API endpoint with not putting so much burden on the developers to react to the changing customer needs?

 This is where API access gateways come into play. They’re a great tool and intercepting your API requests and inserting security on top of it. Again, they represent a centralized solution that will allow you to standardize how the interactions and intercepts are taken, so that you are assuring that security is maintained across all of your applications.

 In this example here, we’re going to set up a simple route for our stacks API. And then we’re actually going to go through insecurity and a few easy steps.

 What I like to call out about calling here is the calling has an expansive set of settings that you can use to control the security across your APIs. And what we’re going to do is to take a look at some of the variations that we can do when setting this up.

 One example that I like, is being able to restrict certain methods. So let’s say that I have a current operation that I want to do on the snacks. And you know, I have some single page apps that need to request this information. So I feel like maybe I could just give them the snack list with no particular security, I can actually secure the puts post patches and deletes over the gets and make sure that gets are open.

 Now let’s talk about how we’re securing it. So you might think, okay, I’ve got to learn OAuth. So I can actually do this effectively. Well, not so fast. Kong has a library for open ID connect that will allow you to configure this simply.

 Now, if you couple this with Okta’s API and access management, we give you everything you need to set this up. It’s four main properties, the client ID and the secret to identify it, the issuer which is where the location of the authorization server is, and finally, a customized scope that will allow you to define the authorization for the colors that are calling your application. So very quickly, I’ve defined my scope to be this next scope. And right now, I will click save and my APIs are now secure. So just in a few easy steps, again, you can see all of the expansive properties that you could set for your application if necessary, but just with those four properties, and a few easy steps in con, we’ve been able to secure our APIs.

 Well, let’s make sure this actually works as intended. So let’s see what happens when we go to call these APIs. So as I make my call here, I’m going to quickly just punch in my endpoint for my snacks and I’m going to see something interesting happen, it’s going to let me know that the intercept is actually taking place, I’ll see the redirect indicating, hey, something has happened and it’s been moved temporarily.

 Well, let’s make sure it’s secured by throwing in some bogus client ID and secret. What we’d expect to see here is that the request is rejected with a 401 and a message saying that you were unauthorized, right? Here we go. So we know that the app is secure. But we also have to make sure it’s accessible. So let’s run the final test with a real client ID and a real secret and see what happens.

 As I’m putting this in now. I’ll click return. And hopefully, I get my snack contract back. And look, I’ve gotten this now. So quickly, to recap, what we’ve been able to do.

 Set up our application with some rudimentary scaffolding and a template, get that up and running with auth and actually secure our endpoints with Kong and mature application in place. And that’s taken us about 8 to 10 minutes. Well, what happens when we go this next step further, right?

 Now we actually have to grow the platform. And this happens in a number of ways. Some ways you may have your customers aching to get new features that are pre release so that you can get some feedback and they can whet their appetites with what’s coming. So you may want to introduce something like a user acceptance testing environment which mimics prod as opened up but only to a select set of users.

 We want that to be prod like, but we also don’t want to have to rebuild all the infrastructure ourselves.

 Similarly, if you’re looking to expand, maybe expand into a different availability zone in your cloud provider, or trying to explain globally to hit the needs of some of your customers that are outside of your country of origin.

 These are also scenarios in which you want as similar as possible to your infrastructure but replicated in another location. Similarly, if you’re looking to build resiliency, this is a hot topic now to make sure that you have disaster recovery or fault tolerance, you want to make sure that you’re replicating like for like. Doing this in the old days was trying to just match the server specs on other sites with bare bones machines was very, very difficult and also expensive. But now with the advent of containerization and cloud providers, we can actually do this pretty quickly and also immutably through infrastructure and configuration as code.

 The other thing I’d like to call out is what if your business model has changed, and customers want to interact with you in a different way, and let’s say you’re getting into a multi tenant model.

 Now, you actually have to provision tenants and this is an interesting part, because it may not be as expensive as infrastructure, but you still need the configurations and objects to be created in the same way, but in a new architecture, a new space. So let’s take a look at what terraform can do to help us do that. And as Bharat mentioned earlier, the terraform provider provided by Okta has now been brought into product and is being maintained and grown in the full product lifecycle.

 We’re constantly adding new features to make sure we have parity with the management SDKs and even with our new offerings, we’re making sure that you’re seeing those come on to terraform as quickly as possible.

 Very quickly, in this example, we’ve gathered up all of the Okta configurations and now we’re allowing you to take that Okta configuration and package it up in your Kubernetes container in this example, the same way that you would do any other thing.

 This is meant to be a strong silent partner in your road to maturity, we don’t want auth to be a forefront that’s going to take separate meetings from your time to figure out what you’re going to do with all of the Okta pieces of your infrastructure.

 We want to be along for the ride to make sure that wherever you end up, auth is right there with you. And as you see here, the couple of things that are taking the longest bits of time are the things that you really need to consider. How do I want to deploy those containers? And more importantly, as we get into these AWS records for the DNS, how do I want to network these things together responsibility?

 These are indeed some of the most important things that you need to consider. But we don’t want you having to take time from those cycles for that deep thought to deep think about auth and how that can be replicated in the same ways. And so to quickly recap as we’re deploying the last part of our network for this replicated infrastructure, over the past 12 to 14 minutes, we’ve taken a look at how we can build an application very quickly to rapidly prototype, deploy it, and make it live, mature it, break it from a monolith down into micro services, and finally, replicate all of our infrastructure to deal with our changing customer needs our changing business needs. And all of this is possible with the tools that Okta is providing you to help along the way. And again, I’m very excited with the partnership that we’re creating with JFrog to do this with the JFrog offerings as well.

 Just to end really quickly, now that we’ve got our deployment done, I want to go over the starter Developer Edition and it’s a call to action for you guys to get started with, with your developer journey on Okta.

 If you go to developer.okta.com, you can sign up very easily to get access to all these features here for free. And the ones I like to call out are the authorization, this is what we’re talking about with the API and access management, b2b integrations integrating with other identity providers, adaptive MFA, being able to explore how multi factor authentication can work for your users and your scenarios. And the other one to call out is access to our Okta integration network with tons of pre built connectors to allow you to do many things. I also want to thank you guys for showing up to our presentation today.

 I’m going to kick it back to Steve for some closing thoughts. That was awesome to see all those technologies put together and I’m excited to go build the J hipster app and hook it up with Okta. So I’m going to go get started on that.

 The starter Developer Edition you guys have put together is awesome just for developers to get started and build apps and get it going. We have something similar with the JFrog free tier, so you could do your deployments to Artifactory using a free version of that as well.

 I had a question about like, technologies and different Java frameworks, which you support. So you showed j hipster and API gateways like Kong, how easy is it to hook up other Java framework? So let’s say I’m using Spring Boot or micro profile or korkis, how easy is it for a developer to hook that into Okta? Yeah, so, we have pre built SDKs for Java and Java spring. For some of the other flavors we do offer in our traditional routes through the API access so you would have full access to our APIs.

 Now again, we are working on building out the comprehensive library for these SDKs based on what the demand and the need are. So we’re constantly looking at what are the trends, like, we know that there’s definitely some action going on in the go line with server side rendering happening and some of the JavaScript frameworks. So these are things that we’re really paying attention to. And it’s also helpful that we reach out to customers and talk to them about, you know, what are the technologies that get you excited? What are the things that are going to sort of move the needle for you? And also, like, you know, getting into the intellectual discussions about, you know, what is so alluring about those technologies, so that we can be right there with you to support and make sure that journey stays consistently simple across your favorite languages and frameworks.

 Cool, and I was kind of modeling the behavior we want the audience to do and asking questions. So hopefully, folks have already been asking questions for Bharat and Jeff. And, you know, also shout out and tell us what frameworks you’re using for your JavaScript, your Java, your Python or your go development, so the Okta guys know what is popular and and they need to better integrate with. And one other just softball question to toss out because you were talking earlier about security Bharat and, you know, it’s kind of blown up with the solar winds hack, and it’s just this general issue around supply chain security. So why should developers care about security? Like why?

 You know, we’ve gotten along fine with just basic web auth, why should we care?

 I’ll take that Jeff, if you want to [inaudible] but, you know, I think, you know, when you think about the biggest breaches that have happened, a lot of that is because of not implementing the right code, and actually doing that in house. And so, you know, whether, you know, often if you’re a Microsoft shop, you know, you’ll use Azure Active Directory or something like that, and it’s built in, but if you’re writing it yourself, you know, it’s really, really, you’re taking on a huge risk. And not only are you taking a huge risk, but you’re also devoting a lot of, you know, developer resources and hours to figure out what the heck is LIDC? What the heck is OF 2.0? Like, there’s a lot of conceptual learning you have to do there before you can actually implement these things and also, you’re not doing it in the best practices. And so, there’s a lot of like threat vectors that are just open when you’re writing your own security code, when you’re on your own auth code, and again, at Okta, we’ve hit those problems along the way, along the journey so we know what those are, we know the best way to kind of avoid those pitfalls and also, you know, the whole saving time thing for developers, I think that’s a huge thing. So that you can go do, you know, what you really want to do, which is, you know, build amazing apps or, you know, grow your business, whatever it is, but the other part of it is, you’re taking on a huge amount of risk. So, you know, just some slight mistake and code opens up a, you know, a threat vector. So… and I think, to a larger story, Steve, like, I think that, you know, I like to say this, where it’s not just protecting your apps… sorry, it’s not just protecting your apps and your APIs. And again, we’re building out these like, complex ways to like, augment that API security with Kong and others, but for that info site, too. So how do I automate all that stuff? And then where does that lead to ultimately?

 It ultimately leads to the big security questions, information protection, governance.

 How do I protect myself from, you know, how do I do privilege access management? Al these things kind of come in when you’re using Okta. So let’s say, so you’re, you know, I like to… talking to you guys, at JFrog, I love to say that, you know, automated by JFrog, and secured by Okta, you know, and so you get this kind of, you get this kind of thing where, you know, when you’re thinking and planning how to build your apps or grow your business, you don’t need to worry about that part as much because we’re taking care of some of that heavy lifting for you. And we’re telling you that it’s going to be secure.

 We have SLA there that says, okay, you’re going to get all your signals, the signals coming in that are threat vectors.

 We’re covering that for you.

 I hope that answers… No, no, I think that’s very convincing. And it ties back to that better together story for having an entire platform for building, releasing and authenticating and securing your application. So I think this is critical that it’s not just saving time, it’s avoiding critical threats to your company and to your applications and users. So this has been an awesome session.

 Thanks a lot for inviting me in to do this together with you. And I hope everyone else enjoys the rest of sessions we have at the partner day today. So I’m looking forward to the partnership going together with Okta, and working together with you guys. So thanks very much.

 Thanks so much, guys.

 Thanks for having us.