Oktane19: Roadmap: Developer Experience

Nate: Thank you for being here. Thanks for spending the next 45 minutes with me talking about developer tools. You probably didn't know this but you got a free eye exam as well, if you're sitting in the back at least. So my name is Nate. I work here at Okta. I'm on the developer experience team. I'm the product manager of the developer experience team. And what we do, what my team does at Okta is we do whatever we can to make it as fast and easy as possible for you to build applications and integrations and things on top of Okta's APIs and platform. So we do that a couple of different ways. We build documentation, tutorials, API guides, things like that. We write code samples and sample projects that you can download and we also work on libraries and STKs that Okta officially publishers and supports.

Nate: I'm going to talk a little bit about the first two, but the most of this talk will be about the third one. For documentation and samples, we have a ton of resources available on our developer site at developer.okta.com. We've got code samples there, we've got a ton of documentation. We actually got a lot of really good feedback last year at Oktane of what we still need to improve, what was hard to find, what we needed to add more content on. So we've done a lot of investments and improvements in our documentation in the last couple of months. If you haven't been to our developer site recently, go check it out. It looks very different now. It's got a lot more content. We'll be adding more and more over time all the time.

Nate: But that's not what we're going to talk about too much today. You can go find that on your own. You can go find that online. What we're going to talk about today is developer tools and SDKs, specifically the SDKs that my team builds. My team spends about probably 80% of our time building libraries and SDKs that you can use when you're building things with Okta. The reason that we spend so much time on that is because we think building SDKs is probably the most valuable thing that we can do to help you out and make your lives easier.

Nate: All of the SDKs that we build they're nothing magical in the sense that it's nothing you couldn't write yourself. But if you're building something and you're building an application that uses some of Okta's APIs using one of our SDKs is at least a couple hundred, if not a couple thousand lines of code that you didn't have to write yourself. And it does things like, again, nothing magical, but it makes sure that you retry if you get rate limited or retry if there's a network connection failure or do some caching for you, things like that. That all just makes your job a little bit easier and less code you have to write.

Nate: It also makes common stuff really fast and easy. So a lot of Okta's implementations are built on protocols like OpenID Connect, which are great protocols but can be a little bit, the rabbit hole goes a little bit deep on how those work. So if you're using our SDKs, you don't have to worry too much about the mechanics, the underlying complexity of how those protocols work. You can just drop our STK in, you're good to go.

Nate: It also can help you if you're in a situation where you've got like a polyglot environment, you've have maybe JavaScript on the end, some other language on the back end and your servers and maybe a third language in all your scripts and automation. We have in our SDKs, we have common patterns and common styles that we use in all of our SDKs. Each one is tailored to the language that it's built for. So that it makes sense in Java or make sense in JavaScript for example. But there's also common patterns. So if you understand how to use one of Okta's SDKs you can probably figure out how to use it in a different language as well.

Nate: So this is what we spend a lot of time on and we have a lot of different SDKs that we publish. We have plugins and integrations for popular client and server frameworks, we have SDKs for mobile apps, we have SDKs for using and easily accessing the Okta CRUD or management APIs for like programmatically creating resources. We maintain a component called the sign in widget for browser applications and we build SDKs for doing low level authentication tasks, all sorts of stuff.

Nate: So we're going to talk about each one of these today, but I'm not going to just go through and talk about each one of them in a vacuum. What I would like to do is really two things. I want to walk through some common integration scenarios that may resemble what you're working on so that you can understand where Okta's SDKs fit in, where they make sense, where they might help you out. And also since this session is being recorded, give you something that you can go back to your engineering teams or your PM or your developer manager and say, hey, if we're thinking about using the Okta SDKs here's something you can watch to understand how they fit in. So that when you have those conversations with your teams, you have a common language, you have a common framework to talk about.

Nate: So what I want to do first at the very top 10,000 foot view, I want to talk about the two major types of integrations that people build against Okta. There's more but I'm oversimplifying here to two main buckets. The first bucket is something I call SSO from Okta. In this case you might be a company that uses Okta for your employees. Your employee sign in into a dashboard to get all the apps they need to do their jobs every day. And you might have some internal applications that you've built that aren't off the shelf applications, internal applications that you've built that you also need your employees to access. In this case, you would need to work with the Okta APIs to get your internal apps that you've built to understand how to get an Okta user to sign in from Okta single sign on SSOed into your application.

Nate: Same coin, different side. You might be a software vendor who's working on software that you're selling to your own customers, and you may or may not use Okta yourself, but maybe you're building an application and those customers you have that are also Okta customers say, I'd love to buy your software, your next Zendesk looks way better than Zendesk or whatever you're building, but I'm not going to buy it until you support Okta. I needed to have my Okta users to be able to sign into your application. So that scenario is single sign on from Okta. Quick show of hands, who here is building or it's thinking about building something like that. Cool. Okay. Like 30% of you. Awesome.

Nate: The other common integration scenario is what I call Okta as a user store. So this is a little bit different. This is coming at it from a different angle. In this case you might be building any application, could be internal, could be external, could be I don't know, something. And instead of maintaining users and identities and building out a password reset flow and building a password hashing and building account recovery and multifactor, all that stuff. You basically take, instead of having a user's table in your application, for lack of a better term, you would not have a user's table and you would instead use Okta's APIs to store your users, do all the password reset stuff, do all of the account recovery stuff, do all the MFA stuff.

Nate: That's using Okta as a user store. Now the big difference between these two integration patterns is that on the first one with SSO from Okta, it's very explicit that Okta is in the mix. You either have Okta user signing into Okta and then clicking up an icon on the Okta dashboard to get into the application, or maybe in the application itself there's a button that says sign in with SSO or sign in with Okta. That's very explicit, but if you're using Okta as a user store that's a little bit more under the hood, it's more just a component of your application. So your end users may not even know that your application uses Okta's APIs for like user storage and identity management and stuff.

Nate: Just like your application might send a text message to your user.. Twilio but your users don't actually know it's Twilio that's sending the text. They just know they got a text. Now these two integration patterns are not mutually exclusive. You could have an application that actually is both of these things. You could have an application that the users are stored and managed in Okta and also you allow Okta users to single sign on into your application. So you could see the same thing in both applications or both of them in the same application. Quick show of hands, who is working on the Okta's user store type of scenario? Anybody here? Okay. Like 50% awesome.

Nate: So I wanted to call this out at the beginning because some of the tools that I'm going to talk about in the rest of the talk apply to both of these scenarios and some of them apply only to one of these scenarios, but I want to call out and just explain when it makes sense to use one or what tools apply to what scenario. So let's get into it.

Nate: I'm going to talk about a couple of really common application architectures that are a little bit simplified but should represent something like the applications that you might be building. And I'm going to talk about where the Okta SDKs fit in and can help you build those applications a little bit faster and a little bit easier.

Nate: Let's start with a really common application architecture or a single page app. You've got an application running in the browser, JavaScript application running in the browser and it makes API calls to some backend somewhere that's hosted, maybe your own API or an API gateway or something like that. The common industry pattern for signing user into that type of application is to have the front end application, go talk to something and get a token for that user that represents the fact that the user signed in and then attach that token to outgoing API request to the back end so that the back end can know those calls are authenticated.

Nate: So if this looks something like the architecture that you're working on, what we've built is we've built some client SDKs that help you do that, signing the user into the front end piece really easily. We built these for angular, for react and for view. Probably the three most popular front end frameworks today. And what that client SDK does, our angular SDK for example, it makes it really easy to sign the user into Okta or sign the user into your app via Okta. And you can do that either by redirecting to a sign in page hosted by Okta or by using a sign in page that's already built inside of your application.

Nate: Either way, the SDK is helping you get that token that represents the user has been signed in, store it inside of your application and then attach that token to outgoing requests to your API so that you can authenticate those requests. Instead of having to write all that code yourself and figure out OpenID Connect, the SDK lets you do it with a couple of lines of configuration and maybe like one line of code, a couple of lines of code.

Nate: On the backend side of things, once you've gotten that front end working on the back end, we also have server SDKs. If you're building your back end API in Spring Boot or ASP.NET, ASP.NET Core or maybe Node Express, we have a similar SDK on the backend side that helps you take that request that's coming in, take the token out of that request that's coming in and verify the token, make sure it's a valid token, make sure it hasn't been forged or compromised or isn't totally fake. And also give you some information about the user that owns that token or the user who is associated with that token. So your API can make authorization decisions and things like that.

Nate: So this is a really common architecture like I said, a little bit over simplified, but this helps you understand hopefully where the Okta SDKs might plug in. We've separated these SDKs out to front end SDKs and back end SDKs because we know people mix and match these languages. So you might have view on the front end with Java on the backend or you might have angular on the front end .NET on the backend. We let you mix and match and just pull the SDK that makes sense for your environment.

Nate: Another really common type of web application architecture is a little bit older than the single page architecture. This is a style where the front end and the backend is one monolithic application and the backend renders templates to send HTML down to the front end. Sometimes this is called MVC. This is popular with Spring ASP.NET MVC and Express with templates like Jade or Pug. And in this case, if this is more like what your architecture looks like, those server SDKs that I already mentioned already make it super easy to help you do both. To sign in the user, get information about the user, keep the user signed in, signed the user out if they want to log out, things like that. And it works exactly the same way.

Nate: Now if we think about mobile applications, oh I'm sorry, I'm going too far ahead. Let's talk about what we're doing to make those SDKs that I just mentioned a little bit better. So we have, like I said, client SDKs, server SDKs. On the client side, we actually do a lot of work to keep up with just how fast the JavaScript ecosystem moves. So we're just keeping up with like how quickly angular does releases as quite a bit of work. So we're making sure that we support the latest versions of things like angular. And we're also keeping up with various like industry best practices. So if you pay attention to the OpenID Connect world, you know that there's a lot of discussion going on right now about moving away from the implicit flow and moving towards the authorization code flow for getting tokens in browser apps.

Nate: I'm happy to chat with you more about that if you want to know about it, that rabbit hole goes like pretty deep. But we are improving our client SDKs to support that flow if you want to do that and eventually that'll be the default in our client SDKs. But the long and short of it is if you want to keep up with the latest industry best practices, our SDK will have you covered. You don't really have to worry about how it works under the hood, it'll do the right thing.

Nate: On the server side, our server SDKs are pretty mature there's not like a huge feature gaps there right now. But there are some things we can improve. Right now our server SDKs are really focused on getting the user signed in kind of the authentication side of things. There's other things that we can make easier such as sometimes you have flows where like the user requests a password reset, then they have to go to their email, get a code to complete that password reset. Then they click on a link, come back to your application, redeem that code and they finish resetting their password. You can do all that stuff today but it could be a little bit easier. So we're going to be improving our server SDKs to help you handle those situations better with less custom code that you have to write.

Nate: And then also our server SDKs were originally written just for the Okta as a user store scenario in mind. They do actually work for the SSO for Okta scenario as well. But the configuration that could be a little bit easier, it's not super well documented today what the configuration you need is to get it working in that scenario. So we're going to be making that easier as well. I should mention also upfront, I'm going to save quite a bit of time for Q&A at the end here. So if you have questions I'll definitely get your questions at the end. I'd love to get some good feedback on this stuff.

Nate: So let's talk about mobile apps. Our mobile app architecture looks almost identical to the single page app architecture if you just take out front end and put mobile app in that square, instead you have a mobile app architecture, your mobile app is going to sign the user end, get some tokens about the user, and then make some calls to your backend to make authenticated requests on behalf of that user. So we've done the exact same thing we have in the single page app world here in the mobile world. We've built mobile SDKs for IOS and Android that help you sign the user in, either by opening up a browser to sign the user in, which is sometimes called the app off pattern or by building out native UI screens that are custom to your application to sign the user in.

Nate: Either way, you're getting a token for the user that your mobile app holds onto. We make it easy to store that securely in like secure device storage on IOS, like in the key chain for example. And then the backend API side of it is exactly as the same as we discussed before. You're making a request to your back end API, those requests have that token, you can use those ... it's too far. You can use those server SDKs that already talked about to make your backend aware of those requests and make it able to process those correctly. We've actually put a huge amount of investment into our mobile SDKs in the last six months or so. We've got a lot of feedback from folks wanting to use them, but it didn't quite have the features they needed, so we went back, put a lot of work into those and we've rolled out quite a bit of features recently.

Nate: For example, the ability to sign users in with native UI instead of opening up a browser. We just released that a couple of weeks ago. We fixed a bunch of bugs, make things lighter, less dependencies, all that good stuff. We have a lot of stuff still coming though. One of the biggest things I've heard people ask for is the ability to hook into things like face ID, touch ID biometrics. To do what ... this is not an industry term, but what I like to call Robin Hood style authentication where a lot of banking apps do this, open up the app, if you've already signed in before it all it asks you is to do a touch ID or face ID to get back into the app the second time.

Nate: You can actually do that today already with our SDKs, but we can make it easier to do, cut down on the custom code you have to right. I mentioned that you can build custom native UI design the user in. It's a lot of work to do that. So we're building prebuilt UIs and really well fleshed out examples so you can just copy and paste code in or steal our code and use it. It's all in GitHub.

Nate: And then we'll also be building out support for folks who want to build more multifactor scenarios into their apps. So if you're building your own mobile app and you want to do code style MFA, like you're building your own Google authenticator app for example, you want to generate codes or you want to accept push notifications for MFA, we'll be building probably a small lightweight SDK alongside our mobile SDKs to help you do that as well.

Nate: Quick show of hands, who here is building mobile apps or is thinking about building mobile apps? A few. So we've built out, I mentioned support for IOS and Android that's Swift and Java. And we wanted to start there because that's what most people use. But there's also folks who build mobile apps using kind of like app frameworks like Xamarin or React Native. So we don't want to leave those folks out in the cold either we're going to be building a support for Xamarin really soon. We already have some support for React Native, but we'll be improving that as time goes on.

Nate: Is Anybody here actually using React Native or Xamarin? Oh, awesome. Okay. Well talk to me after I'm really interested to hear what you're building with that. We're going to be adding more support for that very soon. Okay. Mobile SDKs, we talked about client SDKs. We'll talk about another type of SDK that kind of lives inside of your application. So far we've been talking about like signing users in, getting tokens for users, but what about if you need to do kind of programmatically manipulate Okta resources. This is coming at it from a little bit different angle. Let's say that you want to programmatically create users or you want to programmatically reset a user's password based on some automation that you have. Add a user to a group or remove them from a group. Things like that.

Nate: Okta has a bunch of APIs that help you do those things. User's API groups, factors, applications, identity providers and the list goes on. But to save you from having to build write custom HTTP code and custom retry logic code and custom cash and code and all that stuff for each one of those APIs, we built a set of what we call management SDKs that help you call those APIs really easily.

Nate: So this is primarily today only used on in your backend. So on your server or on your API backend when you need to manipulate these Okta resources, these SDKs currently require you to have an Okta super user API token. So you can't use it in a front end app where it might leak from the browser or in a mobile app that you're shipping to someone's device because they can decompile the app and find that token. But if you're in a trusted environment like your server, you can use these SDKs to call those Okta APIs and do basically whatever you want.

Nate: We've built these SDKs out for a go right now in Beta, Java, php.net, Node. And what these SDKs do is give you just a nice HTTP abstraction layer over the Okta APIs. we're going to be improving these ... test, okay. We're going to be improving these in the next couple of months with a few things, I mentioned the Go SDK is currently in Beta. We're going to be moving that to stable. It's been in Beta for a little while. We got a lot of really good feedback on our Beta so far. If you're using are Go SDK I'd love to get some feedback from you during Oktane as well.

Nate: We wanted to understand the different scenarios that people are using our Go SDK in and we got some great feedback on it. So we're going to be moving that to a stable release pretty soon. I mentioned that right now all of these SDKs require a super user API token so you can't use them in a browser app. Very soon we're going to actually be kind of erasing that boundary because if you went to any of the other talks here at Oktane, if you went to a John Grundberg roadmap talk for example, he talked about how we've recently been starting to roll into Beta, the ability to call Okta APIs with OAuth tokens, sometimes called OAuth for Okta APIs.

Nate: What that allows you to do is have very scoped, limited access tokens from Okta that let you call some of the APIs like the user's API but not all of the Okta APIs. And that was kind of a prerequisite to allow us to use these management SDKs in more scenarios like in a browser scenario for example. Because we don't want you to put a super user API token in the browser. Now that you don't have to do that anymore, we're going to be enhancing our management SDKs to be able to do that. A scenario you might use that in is if you're building a front end application and you want the user to be able to edit their profile for example.

Nate: Currently you would have to have your front end application send a request to Okta and then resend that request oh, sorry front end application send a request to your backend, then your backend kind of resend a request to Okta using that super user token in order to make the profile change to the user's API. But with the OAuth support for Okta APIs now you can just have the front end call Okta directly with the right scope token so you can eliminate one of those steps. Faster, easier, more secure, all that stuff. Well not more secure, it's already secure but faster and easier.

Nate: If you've seen any of the other presentations here at Oktane, you've seen us talk about our new hooks feature, who had a chance to play with the hooks feature? Did you go to the dev hub? Awesome. A couple of folks. Hooks is really exciting it lets you do a lot of custom extensions to Okta's behavior. And if you've played with the hooks feature, you know that the way it works is basically an inversion of the normal HTTP request response pattern. Instead of you sending a request to Okta, Okta is actually sending a request to you and you have to respond with a specific payload or a specific response to tell Okta what to do next.

Nate: So that's something we think we can also make a lot easier with SDKs. We're planning on building some SDKs to help you parse that payload that Okta sends you, understand what Okta is asking you to do and then send the right set of commands back to Okta deny a login or approve it or enrich a token or whatever you happen to be trying to do with your hooks. So we'll be working on that coming up pretty soon as well.

Nate: I'm going to go back to a slide that we already saw. This is the first slide I showed about the single page app architecture. And I kind of glossed over something the first time. I said that the client SDK helps you sign the user in via Okta. I said it kind of used OpenID Connect under the hood and you could use the Okta sign in page or your own sign in page, but I didn't really explain how that works. So if we zoom in just to that part, if regardless of whether you're using a sign in page hosted by Okta or a sign in page inside of your own application, you're going to be using the component that we built called the sign in widget. The sign in widget is a JavaScript component that is basically a prepackaged bunch of UI that's all packaged up together that calls a very low level API that has called the authentication API.

Nate: The authentication API is what actually signs users in to the Okta system. But the authentication API is pretty large API. It has a pretty complicated surface area because it has to handle situations like user attempting to sign in, they're locked out so they need to get a reset code, they apply the reset code now they have to be challenged for a factor. They've got past the factor challenge, they submitted the code, now they're able to sign in and things like that. Just got a pretty big surface area there's a lot of ways you can kind of go through the authentication API. A lot of paths you can go through.

Nate: So it's not too common that you'd need to write code directly against that authentication API because there's a lot of edges you have to handle if you do that. What the sign in widget does is it has UI that covers all of those cases already for you. So if you are building a sign in page or you're using our sign in page which uses this component, you'll be using the sign in widget. Now the sign in widget, like I said, it's a JavaScript component you can drop it on any HTML page and it's a pretty mature component. It's got a lot of features built already. It works pretty well. A lot of people are using it in production. There's plenty of improvements we can make on this as well.

Nate: The improvements that we are currently looking to make on it is to improve the accessibility of the component. So making sure it's as Section 508 compliant as possible. Making sure that we have ARIA tags on all the right places and all that stuff so you don't have to worry about accessibility concerns on that component in your application. As well as making the configuration a little bit easier. It's a complicated API so it's a complicated component in some ways. The configuration is unfortunately kind of complicated, sometimes too depending on what you're trying to do. So what we're trying to do right now, what we're working on is making the configuration have a lot more out of the box of defaults that just work. So you don't have to dump a massive configuration blob in there just to get something working out of the box. The defaults will work really well. You don't have to do too much to get it working. If you want to customize things you can.

Nate: We're also looking at adding more customization abilities to it. Right now you can drop your own CSS file on there to customize the look and feel, but that's kind of limited sometimes. If you're using the sign in widget right now or if you have tried using it and you have some feedback on how to make it more customizable or how you would like to see it more customizable, please come talk to me afterwards. I'd love to get some feedback on what you'd like to customize, how you'd like to make it better. That's something that we're looking at doing right now.

Nate: I'm moving onto the last category of APIs that we maintain on my team. I mentioned that the authentication API is a pretty low level API, pretty complicated, pretty powerful. You don't often have to write code yourself against this API because most of the time you could use the sign in widget. But if you're in a situation where you can't use the sign in widget, you can write code against this API yourself. And to help you do that, we've built a set of authentication SDKs. These are separate from our other SDKs because they're just focused talking to this relatively complex authentication API. And we built these for JavaScript, for Java, for IOS and Swift, .NET and Node

Nate: One scenario where you do have to write code directly against this API is I mentioned before in mobile apps. If you have a mobile app and you have a hard requirement to build the sign in experience in totally native controls and you don't want to open a browser to sign the user in, you'll have to write code against this API, which is why we built an SDK for this in Swift, for IOS and in Java. We don't have much roadmap on these SDKs because they're pretty well built out. They do what you need to do. Not a whole lot of people need to use them all the time so there's nothing that we're specifically working on in these, but if we get any feedback, I would love to take another look.

Nate: So that's a pretty whirlwind tour through the SDKs and libraries that we build to maintain here at Okta. I should mention that all of these SDKs, all the stuff that I mentioned already is all open source. It's all on github.com/okta. So you can look at the source code, you can post issues, you can ask questions, you can post bugs, that's all we'd like to build all of that stuff out in the open. Nothing magical like I said. So I talked a lot, hopefully that was helpful information for you or helpful information for your teams. I would love to get some feedback from you on all sorts of stuff.

Nate: So I'd love to hear from you on what documentation you would like to see but aren't able to find. I'd love to hear about all the frameworks and libraries and languages that you're working in that I haven't mentioned up here. And I would love to just know more about what you're building. Are you building mobile apps, internal apps, external apps, all of the above. None of the above. I'd love to get all sorts of feedback from me.

Nate: So I'm going to open up for Q&A, if you have a question, raise your hand, go get a microphone to you. We've got some time for Q&A, so let's chat and if we run out of time I'll be down at the dev hub afterwards. You can come find me at the developer hub, which you can't miss on the expo floor. It's like right when you walk into the expo floor and we can keep the chat in there. Thanks for your time.

Speaker 2: Hello? I'm an Okta admin and I use a Python for a lot of the admin work. So is there SDK in Python available at this point?

Nate: I knew somebody was going to ask about that. So I'm happy that that was the first question we got. The question was are we going to have a Python SDK? Actually keep the microphone I have a followup question for you. We used to have a Python SDK but it was not fully built out and it didn't work very well, so we ended up actually deprecating and just so we didn't confuse people. We do have plans to build a Python SDK, but it's not like in the near term, it's more like a little ways down the road. I'm curious to hear though you said you're an Okta admin. What do you want to use a python SDK for?

Speaker 2: Like typical activities like adding people to groups. It's very common activity that people ask us for. So they send us like a big list of people that need to be added to a particular Okta group.

Nate: And is this something that you want to do, like from a script? Like a Python script that you wrote?

Speaker 2: Yeah. That's what I do.

Nate: So it's not like in a web application, it's more like you're scripting it so you don't have to do the clicking yourself.

Speaker 2: Correct. Yeah.

Nate: Awesome. Okay. If anybody else is also using Python in that way, please let me know. I'd love to hear about it. Any other questions? Look like if we have another mic, there's one way in the back as well. Go for it.

Justin: Hi, my name is Justin I work for Nordstrom. On our organization we have essentially one sign in page that all apps that are onboarded have to share. Is there any possibility or anything in a roadmap to customize sign in page at the app level?

Nate: Yeah. If I understand your scenario correctly, you're saying that you have, is it multiple brands? Okay. So you have like one Okta org, but there's many applications that kind of share one sign in page, and based on what application someone signing into, you'd love to customize the way the sign in page looks so that people think it's more than one sign in page when it's really one. Yeah. So there is actually a way to do that today. So we have the feature called custom sign in page. So it lets edit the HTML and CSS of the page.

Nate: And one thing that we do when Okta renders that page, it actually also in part of the there's some JavaScript on the page that dumps out the application ID that is basically being logged into. So today you can actually use JavaScript on the page to look at that application ID and then you could like swap out the CSS file that's on the page or swap out some elements on the page or whatever. So you can do that today. We actually have a code sample that I can share with you if you shoot me an email.

Nate: There's a code sample and how to do that today. And then looking towards the future, in the identity engine that my colleague Wills Dawson is working on right now, that specifically like multi-app branding is what is being built into like the low levels of that identity engine as well. So you can do it today, kind of like a JavaScript work around, but you can do it today and then in the future with the identity engine that's also planned as well.

Speaker 4: So just real quick, you can add another vote for the Python SDK. We've got basically the same use cases, automating and scripting the admin tasks.

Nate: Okay. So you are writing scripts in Python and you would love to hit the Okta API from those Python scripts?

Speaker 4: Absolutely.

Nate: Awesome. Quick question, is anybody writing scripts in PowerShell? Oh, wow. More PowerShell people than I expected. So scripts in Python? All right. Anybody doing scripting in Go? Maybe, a little bit. Okay. Bash? More than I expected. Okay. Awesome. That's really helpful feedback. Thank you. What's that? Ruby? Groovy?

Speaker 5: Yeah.

Nate: Groovy you could use our Java SDK actually, it's compatible with Groovy.

Speaker 6: So I'm using your react SDK. And with the implicit flow, when we get error with the user logging in, we just got the error outputted to the page in way of capturing the error on the client side, is there any plans to update that so we can handle those errors a little bit better?

Nate: So you're saying that when ... okay so the user is trying to log in and they get an error, is that the first time they log in or is it like?

Speaker 6: Yeah, the first time. So for example, if they're not actually assigned to the application, it just comes up saying user error, user is not signed to the application and because it's inside the react component, from outside of that, I can't capture the error.

Nate: Gotcha. Okay. I know that we've looked at that before and I think we fixed part of that. Come chat with me afterwards about that. I'd like to get a little bit more detail. Yeah. We either planning to fix that or we thought we fixed it and it sounds like maybe we didn't. So let me get some more information from you. We can definitely fix that.

Speaker 7: So building off the Python SDK stuff, have you guys thought about like Ansible modules for managing Okta resources or even just a declared of API kind of like cloud formation or Kubernetes manifest.

Nate: Ansible modules? This is not something that's on our roadmap right now. I would be interested in getting some more information of what you're doing. We've thought about like, there's a pretty short step from our Go SDK to like building like Terraform components and stuff. We haven't looked at Ansible specifically, but you're like managing Okta resources in like a DevOps environment?

Speaker 7: Yeah, exactly. I have an Ansible playbook kind of just doing a bunch of curls, so it'd be nice.

Nate: Yeah. Is your primary need to manage like spin up like QA environments that have a very specific configuration?

Speaker 7: Exactly. Yeah.

Nate: Gotcha. Yeah, we haven't focused too much yet on like the DevOps folks, sorry to say. We've been focusing on like the just making sure the sign in stuff works really well. I expect that we probably will focus on making DevOps stuff scenarios better. Come chat with me after as well I'd love to get some more stuff from you on that.

Speaker 7: Cool. Sounds good. Thanks.

Speaker 8: Oh, hi.

Speaker 7: Hi.

Speaker 8: I had a question like, do you guys have support for CAPTCHA on your sign in widgets ?

Nate: CAPTCHA?

Speaker 8: Yeah.

Nate: That's a good question. I've actually got that question a few times recently. We don't have support for it today. And one of the things that of kind of falls into the bucket of feedback I'd like to get on a customizing the sign in widget. There isn't today, there's not a way to like set a configuration flag to turn on CAPTCHA or even put like customizations in there. You're trying to do capture on the sign in or registration?

Speaker 8: For both.

Nate: For both. Okay. Yeah, not possible today, but that's really good feedback.

Speaker 8: Okay. And one more question, I had a similar question related to SDKs. Is there any plan to have Scala SDKs on the server side?

Nate: No current plan to build Scala SDKs but my understanding, correct me if I'm wrong, I'm pretty sure you can use our Java SDK, it's built on the JDK or the JVM. So I think you could use our Java SDK. It might not be like Scala E but it should work. Yeah. Just out of curiosity, are you building like a web application in Scala?

Speaker 8: Yes.

Nate: Gotcha.

Speaker 9: I have a question about user management. We are new to Okta and we somehow we have 100 more application with 100 user stores. So, user migration is kind of taboo in our organizations so we kind of prefer an integration. So do you guys have planned to publish some SDK and to make a lot easier and then to integrate with customer and existing user stores not ... so do some what .NET so you guys are going to publish some kind of middleware for us to you say hookup to custom user stores?

Nate: Good question. If I understood your question correctly, you're trying to get a bunch of users who are in some other user store right now into Okta?

Speaker 9: 100 databases

Nate: A 100 databases. Got It. We don't have any specific import tools today other than like you can use our SDKs to make API calls or write a script to import a bunch of users.

Speaker 9: Can you import CVS into Okta?

Nate: Yeah we do have the ability to import a big like CSV dump into Okta, obviously if users are in like AD or whatever, you can get them into Okta. Come find me in the developer hub afterwards. I'm not the right person to answer it, but I can connect you with the folks. There's a group at Okta who are specifically just thinking about like making user import better and they would probably love to get that feedback from you. Great question sir, I appreciate it.

Speaker 10: So I have question whether SDK is not supporting right. So what are those steps or documentation you are providing to develop the SSO or protect under the Okta.

Nate: Can you move the mic a little closer and repeat the question? I didn't hear all of it.

Speaker 10: So like a Ruby real type of application, there you don't have a SDK. So what are other option or documentation you provide to that application?

Nate: Did you say ruby? A Ruby application?

Speaker 10: Yeah.

Nate: Yeah. So for the languages that we don't have support for we have kind of the base level, what we have in our documentation is just like documenting our rest APIs, documenting all the protocols that we support. So if you need to build it yourself, you can. And then our SDK is kind of sit on top of that for the language that we do support. We don't currently have a Ruby SDK, I'd be curious, show of hands, who is building in Ruby? Couple, two hands over there. A couple of folks. Yeah.

Nate: So we actually have ... while we don't have a Ruby SDK specifically, we do have a couple of.. what is it Ruby? For ... I forget which framework it is in Ruby. It might, yeah, I'm going to say wrong if I forgot, but we have a couple of samples on how to hook up some generic like OpenID Connect components in Ruby that work with Okta. But just to your question, what recommendations I have I would say, if you read through our documentation for like signing users in, for example, it'll show you how to do that with just the raw like rest calls. And you can either find components in those languages like Ruby that do like middleware that does the OpenID Connect stuff. Or you can write it yourself, which is not super great, but it is possible. Hopefully I answered your question if not, come see me afterwards.

Speaker 11: I had a question about the documentation of your rest APIS. I noticed you guys are doing stuff with Postman. What else have you thought about in terms of documenting perhaps like open API swagger and even going so far as having maybe Jason Schemas for bodies? There's a lot of complex bodies and it's hard to figure out everything there. Thanks.

Nate: Yeah, I love that somebody asked a documentation question because documentations like near and dear to my heart. So we've actually thought a lot about it. Internally for our SDKs, we actually do have a partial Swagger spec for some of our APIs that we use to like test our SDKs and stuff. We haven't published that because it's not totally completed. It's missing some stuff. So it's not like really great for external consumption. Right now we just have less documentation on our site. What we would like to get to. It'll be a little while before we get here, but what we'd like to get to is that the documentation itself, our documentation site acts more like you see in kind of swaggerified documentation where it shows the API call that you need to make. You might be able to just test it right there by clicking a button and seeing the response immediately.

Nate: As far as publishing like an open API spec or a Swagger Spec of our APIs, I don't know, I'm not sure. It's certainly something that we would consider. It's also a pretty massive project because our APIs are really big. So right now we're sticking with the Postman collections, which is kind of like good bang for the buck, not too hard to build. But that's really good feedback. Thanks.

Speaker 12: Question. So client SDKs to help with the authorization, is there anything special or specific for Okta or could you use that perceivably for any authorization request?

Nate: Is your question, can you use the Okta SDKs with other OAuth providers or is the question can you use other OAuth SDKs with Okta?

Speaker 12: Can we use your client SDK to go against the other authorization service.

Nate: Probably, I haven't tried it. But probably, so they're all built on like standard OpenID Connect. We're not doing anything weird. The only thing you might run into is that because we primarily are intending them to be used with Okta like the way you can figure the SDK is sometimes kind of Okta specific. It's like you'd like you put in an Okta domain instead of like authorization server base URL or whatever. But like if you can figure out the configuration piece, it should work. Yeah.

Speaker 12: Cool. One other question. You're talking about the client SDK could be used to manage like Okta in the future?

Nate: Yes.

Speaker 12: The management APIs. So when you're talking about like I can have scoped access to edit the user profile information, but how are you dealing with the permissions at the user level? So that particular user can do like these particular users or just the user of the access token, like using the mind pattern or ...

Nate: Good question. So there's a whole team at Okta and not my team, but there's a whole team thinking about how that like scoped authorization works because there's like a bunch of use cases that really could use those scope tokens. This is just one of them. So I'm trying to think the way that they're doing that is it's pretty granular. So yeah, you could say like a user has a scope to only view and edit their own details or an admin user has the ability to view and edit everyone's details or only one group's details. Like it gets pretty granular. The like simple case is a user has the ability to edit their own details and that's a simple base case.

Nate: But they've thought quite a bit into like further more complicated stuff. If you're interested in that, how that's coming along and maybe trying out the Beta, I can connect you with the PMs who are working on that.

Speaker 12: Cool. Thank you.

Nate: It'll show up in the API before it shows up in our SDKs, but our SDKs will definitely follow along and make it easy.

Speaker 12: Yeah, that's cool.

Nate: Looks like we are just about out of time. So probably room for one more question.

Speaker 13: I'll take it. So we had some feedback from some customers that our widget is a little too heavyweight, especially for mobile scenarios, a little too much latency when it loads up in the shared browser. Are we looking to kind of try to trim that down a little bit, make a little bit more performant?

Nate: Yes, absolutely. So, that's not the first time I've heard that feedback. The signing of widget is pros and cons. It's very well built out. It has a lot of UI and a lot of flows built into it. Con, it's pretty big. G-zipped it's like, I think 700K. It used to be like 1.2 Meg G-zipped but we have been actually putting a lot of work in the last couple of months to cut that down. So we're gonna keep working on that. We can get it a little bit lower. It's never going to be like a 20K component. But we do care about that. We've been dropping that size down as much as we can. We'll probably be able to squeeze a little bit more out of that. Eventually we'll hit a limit where we just can't squeeze it any more, but there's definitely a little bit more low hanging fruit we can trim out to make that easier to load over the wire. Yeah.

Nate: I think we're out of time. I'm happy to answer any other questions that you have. I'm going to go down to the dev hub right down in the expo floor so come find me there. Happy to chat with you with any other questions you have. Thanks so much. I appreciate your time.