Oktane19: Extending Code with Okta

Joel: Hello everybody. Good morning. My name is Joel Franusic. I'm a Product Marketing Manager and a Developer at Okta. And here with me.

Sarah: I'm Sarah Farnswith-Kumli and I'm an Associate Sales Engineer here at Okta.

Joel: Right well today we're gonna be talking about extending Okta with code and you might have been wondering why it was so vague. We were trying not to ruin the surprises in the keynotes, but what we're going to be doing today is going into depth on the keynotes that Jung and the demos that Jung and Taju did during the keynote session. So how many of you here were in the keynote session? Alright, basically everybody. We'll be covering some of what was there for those of you who weren't, but was just interested in knowing who was there. Alrighty, well let's get into our talk.

Joel: Here's the exciting part of our talk, you can bring out your notes and a pens and start taking notes, just kidding. Basically what this means is you probably shouldn't name your kids after of the things we're announcing cause things are subject to change. Alrighty let's talk about the agenda for today. So what we're gonna be covering today are the features that powered the Customer Identity demo that you saw. In particular, we're gonna be talking about two of the new features that Okta launched, the Okta Identity Engine and then Okta Hooks. And then I'll hold your questions until the end-

Sarah: Don't interrupt.

Joel: No interruptions, we're gonna have questions at the end during our Q and A session. Alright with that, let's talk about features that powered the keynote demo. So for those of you who have been using Okta for a while, you probably noticed a few things in the demo that looked familiar, things that you could have done already and so we're gonna be covering what in the demo was things that you can do now and what things you saw in the demo that took advantage of features that are brand new. So one of the things we used in the demo was custom URL. So this is a feature that a lot of people who use Okta to secure their customer identities have a custom URL, which means that the Okta name isn't visible anywhere in your logs or your browser screen and if you'd have been able to see the location bars in those demos you would have seen two apps. You would have seen app.ticketco.org and login.ticketco.org.

Joel: That was powered by an existing feature, which is a custom URL. And in addition to that, all of the parts where you saw Taju logging in, entering in her information, entering progressive profiling questions about herself, those were all things powered by a custom hosted sign-in page. So that was HTML that was actually served by Okta and that integrated in with the custom app that was being demoed. Now what was new was the Okta Identity Engine. So in the demo Taju was able to register for an account without a password and that was something that was powered by the Okta Identity Engine. I'm gonna touch on it very briefly in this session, but there's a session at 2:00 PM, which is gonna go into a lot of depth so I encourage you to go. If you're not gonna be able to make it to that session, I'll be touching a little bit more on what the Okta Identity Engine did in terms of this demo and then we also demoed Okta Hooks.

Joel: So Okta Hooks is the ability for Okta to call out to external systems and allowing you to use Okta in a very composable way. And then finally, just because I like it so much, there's this great tool called Glitch. Glitch is the tool that we used to build out this demo. It's honestly the coolest software development environment since the 1970's era Symbolics machine, which I have in my house and I'm not joking, this is actually really cool.

Sarah: You are old.

Joel: I'm 36. I'm 36, but this system that was built before I was born was really awesome. Glitch is the first thing that comes close to the power of a Lisp machine. Anyway, moving on. Let's talk about the Okta Identity Engine. So I'm gonna touch briefly on the things in the demo that you saw powered by the Okta Identity Engine. Taju was moving pretty fast through that so let's touch a little bit more on what you saw. So the things that the Okta Identity Engine powered in the demo include three of the things. The first things here that you'll see is a password list registration. So one of the new things that you can do with the Okta identity engine is configure Okta to behave differently form it's defaults. So in this case we configured Okta to not require a password. So you'll see there all that Taju had to do was enter in her first name, last name and email, and then she was granted access right off the bat.

Joel: Similarly, when she went in for a higher assurance scenario, which was when she was gonna buy her tickets to the Beyonce concert, she was sent an email asking her to verify that she had access to her email account. That was also powered by the Okta Identity Engine. And then lastly the prompting for her favorite genre of music was another thing that was a part of that where Okta detected that there was a profile attribute in her profile that wasn't yet filled out so before she was prompted to continue or before she was allowed to continue, she was prompted for what her favorite genre was.

Sarah: If I remember correctly hers was pop. So I'm assuming easy listening is your favorite.

Joel: Hey, no judgment okay. I spend a lot of time in elevators. It kind of wears on you. No judgments. Alright so you saw Todd talk about this. Basically what Okta's done is taken our decative experience doing authentication authorization and management of users and distilled all of that experience into these five basic components that we provide same defaults for, but we also allow you to upload rules into Okta to change what happens during each of these phases. And again, this is gonna be covered in depth at our 2:00 PM session, but I wanted to walk you through two of the scenarios that the Okta Identity Engine powered.

Joel: So when Taju first registered, she went through this whole flow except during the authenticate stage what we have done is said in the authenticate bit, given all of the options that she could have used for authentication, we basically said use none of them. So in the authenticate step, we said skip all of them, but because it's a little risky to leave registration open to anybody, what we also took advantage of was in this enroll phase, we configured an Okta Hook to check whether that user registration should be allowed to continue. So that was one set of rules for one scenario. So that was the first scenario, which was registering going into that ticket code pap and just browsing all the listings. The second scenario was when she went to go purchase a ticket. So in that scenario, it makes sense that you want to have more assurance that the person is who they say they are. So in that phase for this step here, we basically said rather than not prompting for any type of authentication credentials to use email. So that's what kicked off that magic link email that got sent out and Okta handled everything from that point on.

Joel: So once that link was clicked, Okta validated that user and then continued the user on through this flow. The other thing that happened is post authentication without actually any configuration on my end, just by defining a user attribute in the app that was tied to that flow, Okta detected that there was a new required user attribute and then prompted Taju for that attribute. So these are all things powered by the Okta Identity Engine. However, I'm gonna just kind of leave it there and continue on to talk about Okta Hooks.

Sarah: So Joel, correct me if I'm wrong, Okta Hooks sounds suspiciously like Web Hooks.

Joel: It's Web Hooks. How many people here are familiar with Web Hooks? Oh excellent, alrighty so it's about half the crowd. For those of you that are familiar with Web Hooks, you've probably seen this presentation here. This is our presentation from Jeff Lindsay who coined the term Web Hooks. This was a presentation he gave in 2008. This is a good video to watch if you wanna learn the history and the influence, but these days Web Hooks are a pattern that is used in a bunch of different places. I'm not gonna touch on everything that's covered in this video or all the other stuff that's available online, but I do wanna touch on one area that's pertinent to what Okta's doing. So let's dial our time machines back to the world of 1970. Back when the people who wrote Unix were teletypes as their interfaces to the PDP 11 you see back there on the screen. The reason why I'm putting my time machine back into 1970 is because of a basic concept that was introduced in that time. This idea of simple programs that did one thing well. Rather than the old kind of batch processing model that happened in the 50's, 60's, 70's.

Joel: A Unix system would have a whole bunch of tiny little programs that would do simple thing and do that thing well and it would allow you to ... basically every program would have a standard input. It would take data in, do it's processing and then give it's output on a standard output. Allowing you to combine them together in a bunch of different ways. So if you're familiar with our modern day teletypes, which are these terminals you will be used to seeing something like this. So in the 90's this is kind of something you would do with this Unix philosophy. So if you wanted to have a report emailed once a week of all the new users added to your user database, you would have written some code that looked something like this. You would have had this shell script, which would probably call your LDAP system to query for all the new users this week. You'd filter that through grep command to get out all the lines that said mail, clean it up with cut, send it over to the mail program, which would then create an email with the subject, this weeks new users and send it on to the admin user.

Joel: Now this might be a little confusing or maybe you're of using a teletype interfaces for your computers so you're like I don't wanna look at this screen anymore so let's think about this from a different perspective. So this basic idea, you can conceptualize it in a different way. You can think of ... with this way of building software, you have a bunch of little composable Lego pieces that can be combined in different ways. So in the example I just gave, it would look something like this. You'd have your custom code, which you then correct with the grep command, the grep command would then be filtered through cut and then you would send it over to the mail command. Now the thing to keep in mind is all these components can be combined and recombined in different ways. This is a set of composable software and that concept is really powerful and one of the key influences beyond this idea of Hooks and Okta Hooks, which brings us to today. So today with the announcement of Okta Hooks, I wanted to cover a little bit about what the problem is that these solve.

Joel: So let's talk about this concept again. Simple programs that do one thing, do it well. However, when we moved from mainframe machines and teletypes into the world of web applications we had a world that looked kind of like this. You'd have systems that you could interact with, but you couldn't connect them together very easily. So since 2008 when Jeff Lindsay was talking about Web Hooks, we now have sites like GitHub, which allow you to connect into stuff like Travis CI and Jira and other systems through Web Hooks. So we now have a world where you can connect them together, but it wasn't always that way. So let's think a little bit more about some scenarios of what this would have looked like.

Joel: So before Okta was around, you're all familiar with Okta or at least I hope you are being at an Okta conference, but this is what the world would have looked like before Okta. So you might have this system where when a new users added to your application, you want that user added to your CRM system, have an email account provisioned for them and the way that it used to look is it used to be you had to have people running the process somewhere. Either someone running a report or typing something manually. However, as you all know with Okta, all of this goes away. Now with Okta and the Okta Integration Network we have on the order of 6,000 integrations now that makes it possible for you to configure Oktas to say when a new users added into your Okta tenant, then you take advantage of prebuilt integrations and add that user to your email system and to your CRM, but invariably you'll find that any company that's more than a couple years old is gonna have some system somewhere that's custom written. In an older company, this might be some old Access Database that's lying around, you can't get rid of it, it's critical to the functioning of your company and there's often times no great ways of interacting with them.

Joel: So yes, we do have technologies like OPP and SCIM to provision accounts to and from systems, but in the modern world we have these kind of workflows that people wanna do. So let's say you have a workflow now where you want to allow users to register themselves into Okta and at time of registration wanna check this existing database, how would you do that? There's no great way of doing that with what we have in Okta. So that's where Okta Hooks come into play. So with Okta Hooks, it changes to look a little more like this where now you can use some custom code that encapsulates your company's specific rules and knows how to talk to your company's proprietary systems and you can now have this code interface with Okta at various points. So in the example we're giving here, we're talking about self-service registration and you wanna say at time of registration I want Okta to ask my custom code, say hey the new user's registering, what should I do? And then your custom code can do what it needs to do. Maybe you just want to only allow people from a handful of domains to register, in which case you're done.

Joel: You could say yes let that one user in or no don't let them in, but following with the example, you could have your code check this custom database and depending on what's there, it would respond back to Okta and then Okta would then proceed on as follows. So this is a lot to take in I realize, but the basic thing to keep in mind is the following. Basically keep in mind that with Okta you now have the ability to have Okta be part of this composable systems of tools that you can connect into existing workflows and systems that you have already and allow you to build off of that.

Sarah: So at this point is everybody asleep?

Joel: I think a few people are asleep.

Sarah: We just went through a lot of slides.

Joel: We did go through a lot of slides.

Sarah: Were we gonna show any code?

Joel: I was hoping to show some code, but I didn't get it done in time. Could you show them some code?

Sarah: Yeah let's take a look at what we did this morning.

Joel: Okay good cause I wasn't sure what I was gonna do at this point.

Sarah: Dance around.

Joel: Alright.

Sarah: Let's kill this Power Point.

Joel: Alrighty.

Sarah: Alright, cool so we're gonna take a look behind the scenes of the demo you saw this morning and how it was made possible. And as Joel mentioned before, it's all hosted live at glitch.com/~ticketco. So you can absolutely find this and fool around with it yourself. So also we're gonna assume that everyone here has had some familiarity with node and express-

Joel: Wait, what if I'm a ASP.NET developer?

Sarah: Joel, you are really old.

Joel: 36.

Sarah: Well okay you've done some web development, this is probably not a foreign language to you.

Joel: Alright.

Sarah: Cool, so we are going to jump in and take a look at our server js. Cool. So we're gonna go through some boilerplate, boilerplate, boilerplate, and it isn't until about here where we're gonna go ahead and load our index. So let's take a look at that. Probably gonna look pretty familiar, we've got some divs, we've got some images, we've even got this neat model down here that is kicking off this browsing login URL.

Joel: What does this all look like? I mean do I have to write this HTML in my head?

Sarah: No I would love to know what this looks like, let's take a look.

Joel: Open up a new window.

Sarah: Yeah, let's open up-

Joel: A new window in Chrome.

Sarah: Yeah. Live demo.

Joel: So this is all available as well online. You can go check it out. I see some of you are in that Glitch already taking a look at the code.

Sarah: Oh rad, you guys are good students. Looks a little something like this right? So if we hover over this register now and we even go ahead and copy that link address, paste it in here.

Joel: So this is how I use the Okta Identity Engine it looks like.

Sarah: Might look a little familiar.

Joel: Yeah. So you'll see up there at the very top, kind of on the extension of line one, you've got the client ID, that's just what connects you in with the OIDC App app that you're using and then you've got the redirect_uri, which is where Okta sends you once it's done with it's authentication and then all the other stuff is just kind of standard OAUTH.

Sarah: Standard OAuth. And if we go back ... losing my windows. There we go. To our Ticket Co, go back our server.js, you can see if we scroll a little bit up, this is where we set that up. Pretty simple. Also if you wanna learn more about OAuth and everything that can go wrong with OAuth, Erin Peracky has an awesome session that's going to be in this very room tomorrow at 2:00 I believe. So definitely would check that out. So this is ... we've loaded our page. Let's go ahead and see what happens when we kick off this registration flow. Cool so we saw Taju successfully register this morning and we saw this navarias hacker try and register as well. So let's see how we made that happen.

Joel: Anyone here named Ernest Baldwin?

Sarah: Yeah I am curious what the story is behind Ernest Baldwin.

Joel: So we were talking with our friends that had Experian and one of the neat things we learned is sometimes in their production systems they need to have a test user and those test users, they have to be people that don't actually exist. So Ernest Baldwin as spelled like that is a person who doesn't exist, unless maybe one of you is named Ernest Baldwin, in which case that's probably why you're having trouble with the TSA.

Sarah: Sorry about that. We should give you a prize if your name is Ernest Baldwin. Awesome, so. Looks like we need some additional user verification. So let's see how we made this possible. Jumping back here if we scroll closer to the bottom, we have this handler for registration.

Joel: Yeah so how does Okta know to call that URL?

Sarah: Let's check our Okta Org. So we have this inline hook set up where again, we wanna extend this registration process. We wanna call out to some custom code before we wanna complete this registration and depending on what it gets back. So let's take a look at that custom code.

Joel: Let's take a look. Let's see what it looks like.

Sarah: Cool. So we have this check identity where if a user is going to successfully pass, we'll go ahead and add them our universal directory and throw in this custom attribute of customer ID.

Joel: Looks like a UUID-

Sarah: Standard UUID. And then if it fails, we're gonna go ahead and deny registration and then we have our mock identity verification, this is a demo, essentially if anyone is not Ernest Baldwin, they're gonna pass. So let's take a look at successfully registering and what that would look like. Awesome. Here we go, kick off this registration flow. And Joel do you have any user who is not Ernest Baldwin.

Joel: Well for test user, I like using everyone's favorite astromech droid.

Sarah: I gotcha.

Joel: R2? What about R5 D4?

Sarah: You are such a nerd.

Joel: Hey, I mean everyone loves R2.

Sarah: Awesome. And cool, no surprise. R2 D2 has registered and is now freely able to browse our application. So let's take a look at our Okta Org, get out of our hook into our universal directory and check it out, we have R2 D2 successfully added, is able to browse our applications and if we take a look at that profile, bada bing bada boom, we've got this customer ID that we've added.

Joel: That's a really good looking UUID.

Sarah: It's the best ID, I think, but yeah that's just an example of one aspect of the demo. Let's take a look at what else is going on.

Joel: Great.

Sarah: I'm sure everybody's got a spare hour.

Joel: Keep going through the code right?

Sarah: Yeah so let's jump back into our server.js ... just kidding. Everything is hosted at glitch.com/~ticketco so you can fool around with it yourself, remix and see what we can do. Find all the bugs that we left for you.

Joel: Alrighty. Thank you Sarah.

Sarah: I got applause.

Joel: So as Sarah mentioned, this is all available online. You can go check out Glitch for yourself if you haven't seen it before. We also have a couple of other things for you to check out. So as I mentioned several times, we do have a session at 2:00 PM today on the Okta Identity Engine. Definitely something I recommend checking out. There are also other ways for you to get in depth on this code. So if you're new to San Francisco, you came with a t-shirt and you're thinking man San Francisco's gonna have nice sunny weather-

Sarah: You're a fool.

Joel: Nope, it's raining. So if you wanna get a hoodie and also learn about Okta Hooks in the process, go check out our Developer Hub down in the expo hall and there's a cool challenge that you can go through where you can get your hands dirty with Okta Hooks. And then finally all the code was showing is available here at glitch.com and then another thing that we're launching here at Okta as well is we're taking all the sample code and sample projects like that Ticket Co demo and we're putting it on place called toolkit.okta.com, which you can also check out as well. So with that, thank you for not interrupting-

Sarah: Not interrupting.

Joel: And watching the demo and now we're open for any questions that you might have. Now this is being recorded so there are microphones to be passed around or if you shout it out I'll repeat it for you as well, but any questions? No questions? There's a question over there. Heckling is fine too.

Sarah: Yeah just shout.

Joel: Looks like we have one over here, one back there. We'll get to you in time. Lena over there.

Lena: Oh there? Sorry, I walked the other way.

Speaker 4: So how are you handling authentication in the Web Hooks? It looked like it was a basic auth, is there any signature authorization to make sure that these Web Hooks are secure?

Joel: So the question was basically, the person there was very astute, was asking how do you authenticate these Web Hooks? How do you know that it's coming from where you intend it to come from, which is the question basically right? So as you will notice here, you saw that we have, essentially, it's not basic auth it's just custom headers. So you can put like a bearer token in there. This is something that's in beta, so we're open for feedback on this. We've talked about doing TLS mutual auth and all sorts of things like that. The very basic, you do have to have ... let's see if this works, it does. You do have to have https and it has to be signed with AITLS search that is recognized or is a commonly accepted route. You can do custom headers, but definitely give us feedback on what other type of stuff that you're interested in using for authentication. Other questions? Over there, yep.

Speaker 5: Yeah so for debugging, is everything through the reports, logging system reports? How would I know if something's gone wrong?

Joel: So for the Web Hooks right? So yeah we do put a decent amount of information, if you're debugging your Okta Hook, we do put a decent amount of information in the system log. However, these are just, in kind of standard web development fashion, there's other places you can insert probes to check what's happening. So for myself, when I'm working with hooks, this is part of why I like Glitch. Glitch gives me the ability to get a log here, so I can see the logging of what's happening as I'm going through here. There's other tools like ngrok, which you can use to ... let me put this up here. Ngrok allows you to expose local hosts on the public internet and then gives you all these great ways of inspecting the http requests that are coming across, replaying them, doing stuff like that. So just kind of use your standard web development toolkit for doing this and if you've got an environment like a Java or .net, you can even set break points and stuff like that to see what's happening. Other questions? One here and there's a couple over here. Yes.

Speaker 6: Yeah so I think regarding the repeat user login. So if the user comes back in, does he have to then enter the email and the password or just two factor or how do they get logged in?

Joel: So this is part of the ... I guess the question is in specific to this demo or just generally are you wondering how that works?

Speaker 6: Yeah if you're not setting the password in the original flow and the user is coming back in, you need to do authentication right?

Joel: So let's take a look here at how this looks. So I'm gonna open up a new incognito window and I'm gonna go to the site here and so what's happening here, I am authenticating here using Okta, you can see that URL there at the bottom. You typically wanna hide that, but for the demo purposes, exposing it there so you can see what's happening and let's do testing user. Testing.user@mail ... so what I'm doing here is registering for a user, a user that doesn't exist in my Okta Org yet. Because of the Okta Identity Engine, I'm not being prompted for a password, but I am being granted a session. So now I have a session, but if I wanna go through this demo and in this case, I just click on that link there. I'm gonna buy my Beyonce tickets. What you'll notice here is I have another OAuth URL, so understands my Okta session, but when I click here it understands who I am, but it's now prompting me for this additional information so it's asking me to log in with or validate myself with this email. So I don't have to enter in that information already, it's based on an existing Okta session.

Speaker 6: Okay.

Joel: We had a couple other questions over here. Yes sir.

Speaker 7: Yeah so if we're a partner of yours, do you support multi tenant Web Hooks? So if we wanted multiple customers, you know Okta customers, to implement our Web Hooks to go against our service, is that supported?

Joel: So I think the way to think about it just generally is that Web Hooks are like any old web application. So the multi tenancies kind of depends on how your app is configured. So you can have multi tenancy in several ways. So you can have if each of your customers has a different Okta Org, you could then have different Hooks configured for that user. You can also have all of your hooks go to your single place and handle the multi tenancy yourself using other hinting information from there, but just think about it as a normal web app. It's going through your front end, going to your back end and I think based on your use case it's also something that you can give us feedback on, but I think your basic things to do would be do multi tenancy either based on having them in separate orgs or you can expose information, the payload that Okta delivers to you to then decide which tenant it should be for. Other questions?

Speaker 8: Yeah so you mentioned with the Identity Engine, you're able to figure out if it's a hacker or somebody who's trying to do the same user ID over and over again.

Joel: Sure.

Speaker 8: It seemed that in your code you had it hard coded.

Speaker 8: So how does the solution do this every day when you can't hard code?

Joel: So the way that it works and this is just a mock code, just cause there's too many moving parts otherwise. In this bit here, let me see if I can get this code a little bit bigger. What you basically see is Okta's making an HTTP post to your application and in that post you have a payload, which is available in this request body. So here I'm doing it with a mock and I'm just doing it based on first name last name, but in that payload you're gonna have everything that was in that user's registration field. So in this case it would be first name, last name, email address. You also get the IP address of the user who is registering and the user agent and that's what we would then expect for you to use with somebody who does proofing or based on your own internal systems to then take that information and make that determination based on that information of whether that user should be allowed in or not. So again, keep in mind this is all custom code that you write so it's intended to be used for your company specific methodologies. We're not doing out of the box integrations, we're opening this up for you to use in your own systems. Does that cover it sort of?

Lena: Sure.

Joel: Yeah.

Speaker 9: So this morning during the keynote speech I heard that Okta gotta runs the AI model behind and to detect whether it's sped or not, so does Okta have plan to open the model up for customer to have the model, look how they trend and then hook up to the Okta pipeline?

Joel: Oh so the questions about the Risk Engine that Todd announced? It's not a product area that I focus on so I can only speak kind of in broad terms, but just generally the plan is to expose all aspects of Okta through Hooks so that you can get more information about that. In terms of being able to train the model or get more exposure to that, I'm not sure about that. So you might wanna go to a session that covers that and asks that there. Other questions? Hi, yes.

Speaker 10: So if I have a use case where the user just submits their first name and last name, I do not want the user to input their personal email address and it should ... the Hooks code should go and check the database, but what is the email address ... I want some custom logic to be built in email address generation or username generation, is that possible using the Hooks?

Joel: So the question is you don't want the user to give an email address, you wanna pull that out of a database or generate it for them?

Speaker 10: Yes, generate for them.

Joel: So there's a couple ways of handling that. What we were showing was at registration time you could do that determination. So certainly you could handle that. So you noticed in Sarah's demo there was a bit of code that responded back to Okta with let's see where was it ... the bit that had the UUID, oh right here. So there's ... at time when you do a successful registration you can send these commands to Okta and one of those commands is to update the user profile. So you could imagine in your scenario, you would generate an email address for them and then rather than updating the customer ID attribute, you could then update their email address attribute or something like that. We also do have another Hook available for import.

Joel: So if you're using Okta to synthesize a bunch of different identity sources, let's say you have an active directory and a work day and some other systems, you'll often have these conflicts. You'll have the third person named John Doe and you wanna determine what their user account should be. You have a Hook into that part there where you can then figure out what the right format should be because every company has a different one. When I was at Microsoft it was only eight characters so like a human would have to come up with a clever one for you. Most companies will have an automated process that you can use so you can certainly do that. Other questions?

Speaker 10: Thank you.

Speaker 11: Hi, in Okta Hooks what format are you using for the events you're emitting? Are you looking at using some of the developing open standards like CloudEvents?

Joel: They are CloudEvents. Other questions? Whoever's got the mic can ask the question, yeah.

Speaker 12: Okay so where do we have a list of all the Hooks that are in there and a way to submit requests for new Hooks?

Joel: There is I believe a beta page. Have you looked into this? Yeah I think so. So I would look into the beta ... so just go through your standard Okta beta process.

Speaker 12: We're on a beta for a few of em, but we want all the best Hooks right? So everything in the logic that we could possibly Hook, for our custom logic, we wanna be able to have that and one other question is in the future when we're getting towards this Workflow Engine, is there an even more dynamic way perceived to add the Hooks?

Joel: So this is in the realm of the forward looking statements. I will speak more just generally, it's http right? So the Workflow Engine that we acquired does allow you to do http based integrations and so certainly, anything that's of course http can be used to connect in. From the little brief ... I only heard about that acquisition a few days before everybody else here did. So I got to play with it very briefly and it does look like you would be able to use that pretty easily. Other questions?

Speaker 13: How many custom domains do you support for one organization? You used to have just one?

Joel: At the moment, so the question is ... so Okta allows you to ... gives you the ability to have a custom domain for your Okta Org and it looks something like this. So for this Okta Org I have a custom URL domain here and so I'm able to say instead of saying Ticket Co, it's login.ticketco.org. At the moment we only support one per Okta Org. I'd say definitely we're always open for feedback around other use cases around that, but let us know. Other questions?

Speaker 14: Hi, do you have any limitations on the kind of Hooks that ... or the kind of events that could be used for Hooks?

Joel: Explain a little bit more and also where are you? Ah, there you are okay cool.

Speaker 14: So for example, are they just user based events or can you do something like when an import happens from a directory and if there's a specific condition, can you trigger Hook on that or?

Joel: Sure so the question is where can you get these Hooks from and I'll answer that. There's basically two basic flavors of Hooks from Okta. One of which is a synchronous Hook. So essentially, this idea that there are certain Hooks like the registration and the import Hooks, which will actually pause the Okta process so you've got like 100 to 200 milliseconds to respond back before the user starts getting grouchy about it and those are available right now in terms of self-service registration and the user import and then we also allow you to add claims or attributes into SAML and OIDC tokens and we're gonna be adding more in that flavor.

Joel: So those are like the ones that will actually affect the user experience. We have another flavor, which is basically events coming off the sys log and those are asynchronous so it can take anywhere from 100 to a couple thousand milliseconds for that Web Hook to fire up from Okta and we're starting with a small list of Hooks, like of events that you can look for and then growing from there. You can also just pull our poll our sys log through the API to look for the events that you want and I do have some sample code on our blog that shows you how to do that. So there's a whole bunch of different ways you can do that. Someone was shaking their head like polling bad, eh yes I agree, but there's all these different ways of doing that. Other questions? Yep.

Speaker 15: I just have a more simple question. When we go through the process to unlock it, is there any license implication? Is there are a certain level ... is there something that's available to us because I'll go unlock it, but I just wanna make sure cost wise.

Joel: So the question is, how is this being licensed?

Speaker 15: Yeah.

Joel: So if I recall, so I'm a programmer and therefore adverse to anything with pricing involved, which is not a good trait, but I believe it's part of Life Cycle Management. So if you're licensed for Life Cycle Management, the Okta Hook should come with that.

Speaker 16: Hello. Question for you. Thank you for the demo. I'm very curious to what a returning user's experience would be? Say for example like a week later, a month later. We saw in your demo signing up and registering and getting that email link. Maybe they went through the process, purchased tickets, what happens if they come back a week later? How are they accessing and authenticating and verifying? Is it the same process every time.

Joel: It would likely be different. So this is like hot off the presses so I would imagine that what you would do at that point, there's different ways you can tune that experience. So I'd say at the very base you'd wanna have a way for them to come in through that magic link because they have no password or in a real world scenario, you might wanna have them use some other type of verifier like a yubikey or an Okta Verify Push or something like that. Ideally you don't want them to have a password. It could go various ways. So it depends on your sort of threat model and your risk stance, but you could have the sessions last a really long, in which case the user returns later and as long as they're on the same browser and they still have their information, they'd come in. Otherwise, you'd wanna build an experience out where they would say well I need to sign in with an existing account and then you would have them enter in their email address and then go through the magic link prompt. Other questions? I think we've got time for more.

Speaker 17: I'm just wondering if there's a way to tie Hooks to a particular application or authorization server because I may not wanna Hook to trigger one every particular registration event, but only for particular applications.

Joel: Sure. So the question was could you have these Hooks trigger not every time, but I'd be interested to hear what the use case is for that? So the basic question is like I don't wanna hook to fire for every event, I only wanna handle a small subset of them. Definitely let us know about the use cases for that, but I think generally you have your engine X do that or your front end do that determination for you and in terms of user experience, you can have that determination done in like 15 milliseconds, 10 milliseconds, it's gonna be fast and then proxy it on to the other downstream system. It's just http, you just do it anyway ... you know like if you have a web socket there that's idling, you're gonna have the same kind of logic there where you're like I don't have any data right now so go away really quickly, but let us know what the use case is.

Speaker 18: So this is what I'm seeing here is like a synchronous interruption to the authorization flow. Are there any plans in the future to have more like an a synchronous pause in the authorization flow where you send them down like a different UI flow like maybe send them over to a UI flow that we're creating as a custom flow where we can grab more dynamic user interactive data and then kind of once we gather that and set up some custom stuff, return back the process to Okta so they can return the access token. Is there anything like that?

Joel: It's definitely something that we're thinking about. It's a little complex and I think part of the reason why we have the Identity Engine is to lay the groundwork for that. The basic question he has is how deeply can I customize that flow so what you saw was all out of the box prompting. So it was like what's your password, enter your MFA token, give us extra information about your user. We have a lot of plumbing underneath so we'd have to give you a way of defining your own UI that would be prompted to the user and these are all things that we're looking into and building the foundation to work for. I would say in the interim there's a lot of things you can do in between.

Joel: So one of the things I've worked with customers on is just putting people into a temporary group that has a lot of ... maybe a lower pending registration group. So one of the things that happens sometimes is people will do like identity proofing. They'll wanna validate that the user is who they say they are. So it can take minutes, days, weeks, so that flow can be tricky so the general recommendation now is put em into a pending state, do your thing out of band and then pull them into the proper groups once they finish that. I think in your case you're thinking more on like the order of hundreds to thousands of milliseconds that you're looking for in that process. It's near term we are looking into that, but nothing really we can talk about right now.

Speaker 19: So it's like the Identity Engine verifies the provided user information is valid against only with Experian or are there any other?

Joel: Sorry, speak up a little bit.

Speaker 19: Okay yep. So the Identity Engine, how does the Identity Engine verifies the provided user information is valid? Is it only against with Experian that you'd verify or should the user be handled in the Okta?

Joel: So the question was how does the Identity Engine validate users? Is that the basic question.

Speaker 19: So like let's say when you are handling with Okta, you provide the information like first name, last name, and email address. How does the Identity Engine verifies that provided information is valid?

Joel: Oh I see. So the Identity Engine gives you the ability work with third party providers. The Identity Engine isn't doing that.

Speaker 19: So may I know like what are all the sources. Like how does it verify?

Joel: So Okta ... the Identity Engine is not like a way of validating identities. It's generally breaking down the various flows inside of Okta. So if you wanna do that particular use case of validating a user, you'd wanna build out your own custom code using an existing kind of proofing company like Experian or some of the other companies like that. It's not built into the Identity Engine, the basics of the Identity Engine is taking this existing framework that we have for authenticating authorizing users and allowing you to plug into.

Speaker 19: Okay.

Joel: You can come find us afterwards. So we're at time now. Thank you everybody. I'll be available, me and Sarah will be just off the side. Come and talk to us if you have questions. Thank you.