 All right, welcome to Okta's Ask Us Anything Developer Edition. So there's three of us online today. My name is Randall. I'm going to be your host. I work at Okta. I am the head of developer advocacy. Our other two special guests today is, first off, we have Aaron Preckie, who is a senior security architect here at Okta. He's also one of the authors of the OAuth and OpenID Connect protocols, and has done a ton of fantastic work in the security community there. And then we have Keith Casey, who's a really well-known API security expert, and he is officially an API problem solver here at Okta. So I think I got that right. So first of all, welcome, Aaron Keith. You guys want to say anything to kick us off? Thanks for having us. Looking forward to it. I'm happy to answer any questions about OAuth stuff today. That is definitely what I spend most of my time on these days. Cool. And Keith, how about you? Yeah, looking forward to kicking around some ideas and seeing how we can help some people out. All right. So the format of this is really casual, just so you know. So if you're watching this online, first off, thank you for coming. Secondly, we will do our absolute best to answer whatever questions you have. So whether that's OAuth questions, security questions, just general programming questions, if you have any stupid questions you want to ask, what is our favorite color, for example? We can basically try to do our best. So with that said, we actually have a list of questions that were submitted leading up to this event. So I'm going to go ahead and get us started by just taking one of those. All right. So I think the first thing we're going to do actually, the first question we're going to answer was submitted by Jace. So thank you for submitting it, Jace. And the question is, what new features do you all have in the works? And so Keith, I think I'm going to let you take that one. So take it away. Cool. So thanks for asking, Jace. First of all, I have to give all the caveats, because we're publicly traded and everything. The things we have in the works, timelines tend to shift just because priorities shift and things like that. But no, we're working on a ton of things. If we go at the high level, the biggest thing we've been talking about the last probably year or so is our identity engine. And that's kind of rethinking the way we architected Okta. If you look at some of the history of Okta, we originally made a lot of assumptions in how we built things. And those assumptions were right for the vast majority use cases. But the space has changed. The use cases have changed. A lot of things have changed. So we've re-architected the change those assumptions into defaults. So now, if you're happy with the way things work, you can leave that default as is. But if you're not, you can now switch that default and do something different. So some of the things we've done with that are our hooks. So web hooks to be able to pause the process in action like authentication, make a call out to another system, and then come back with that response. And then things like event hooks after fact, that's allowed us to plug in all kinds of things, like identity-proofing. So if you're in a high security environment of making sure this is really Randall, when somebody named Randall signs up for the account. Yeah, and all the things go along with it. So it's really fun to do that. And then we're doing stuff all the way down to the protocol level. So there's the things like the device grant type, an OAuth, which I believe was finalized last August. I want to say that we're working on that. That's on the roadmap. We've got token exchange, which I think was January this year. That's on the roadmap. Lots of bits and pieces all over the stack. And just to confirm, you are not telling people to buy or sell Octostock based on these things, right? Correct. I don't want to talk about Octostock at all. Okay. Yeah, good question. I think you should follow your investment advisor's advice. Yeah, fantastic disclaimer. So, Jayce, thanks, man. If you have other questions or need a follow-up, just post in the chat room so we can get you sorted out. All right, the next question was submitted anonymously. So it's sort of a funny one. It says, do you ever look at feedback from customers? And the answer is no, absolutely not. We completely ignore all of our customers. That's why we do these ask me anything because we do not want to answer your questions. But no, seriously, in all seriousness, we have a really great group of user researchers that conduct research on users using the products and get feedback that way. We also have a really active community of Octo users who send us feedback and ideas. And we definitely take those things seriously and we prioritize them. And it's a real core part of our product development life cycle. So good question. All right, next question, let's see. This one might be slightly complicated. Keith, I'm going to give this one to you as well. But it's basically how do you easily migrate on-prem database credentials into Octo? So I'll let you start. I might chime in with some stuff too because I've worked on this quite a bit. And then we'll take it from there. Oh, it's just copy and paste. No, it really depends on what the algorithm is and what the workflow is. So we've got a lot of capabilities around during the authentication process itself, like pausing the authentication with one of our hooks, pausing the authentication, validating it with the original data source, whether that's a on-prem local database or whether that's an active directory kind of thing or even another cloud identity provider, whatever. Authenticate there. Now we still have the rock credentials and then go ahead and create that user on the Octo side of things. That's kind of what we call JIT or just-in-time sort of user creation. But realistically, if you have access to the underlying hashes, I hope they're hashes. I hope they're not plain text. But if you have access to the other line hashes, we can import seven or eight different algorithms and create users out of the box. So it's actually pretty straightforward. Yeah, so I'll also add one other thing. I'll share my screen real quick just because here you go. If you look up, if you just Google Octa user import API, you'll land on our user API here and you can create a user using an import hash password, which is what he's talking about. So you can go here and look through the API documentation. It's pretty simple. And there's a bunch of information down here about what hashing algorithms we support out of the box and then there's other ways to do it for ones that aren't supported. And then the final thing I'll quickly mention is that we are in the future, we've already started doing a little bit of planning for this, but we are going to be releasing an open source tool that you can use to help migrate any relational database user information into Octa. So it'll handle a lot of those API calls for you and figuring out what type of hashing you're using and moving things over, et cetera. So that is something we're going to be working on in the future. So great question. Next up, Aaron, I'm going to pull a question for you. This is from Seismann. I hope I am saying that right. And the question is, given the OAuth 2 token exchange draft has expired, has Octa made any advances in implementing some kind of a token exchange mechanism that allows a client with the token audience X to exchange the token for another token with audience Y? First off, Aaron, I'll let you comment on that if you have any ideas and then I might add a little more context. Yeah, the draft didn't expire. It turned into an RFC. So if you're looking at the token exchange draft, like one of the numbered ones, I think it got up to like 15 or 16 or something, then it looks like it expired, but it's because it got turned into an RFC. So it is done. Now it is complete. So with any luck, we will hopefully be supporting that soon, but I have zero idea about that. Keith might have an idea about the product side of it. So I'll kick it over to him. Yeah, thanks. So yeah, that finalized, I believe it was in January. So it's definitely roadmap. There's three or four different use cases laid out in the actual token exchange spec. I forget which ones were prioritizing, but we're actually collecting feedback from customers to understand like which ones come first. So back to, yes, we do collect feedback from customers. We found that, yeah, we found that most of the time, like not every use case is valuable. So we really try to get feedback from customers of what they actually want to accomplish as opposed to just implementing a spec out of the box. So yeah, that's sort of the mindset with that. That's a really good point. I think that kind of speaks to, in general, how we approach it, which is just because something is a spec doesn't mean we're going to implement it. We really do try to make sure that we're focusing on what customers actually are going to be using. And that does not necessarily map to every spec that exists. Because there's a spec for everything. Great. So Saizman, hopefully that answered your question. If not, please drop a message in the chat. We'll search you out. The next question is from Tim Burns. So Tim, thanks for hitting us up. And it is, can you exchange a refresh token for user information like an email? And if so, are there any articles you can recommend on using a refresh token for this? This is probably an Erin question, but to the best of my knowledge, Erin, and correct me if I'm wrong here, you always exchange a refresh token for an access token. And so you wouldn't be exchanging it directly for a piece of user information. Is that correct? Yeah, exactly. So the refresh token, its only job is just to get new access tokens. And what you do with the access token, refresh token doesn't really care about that. So there is, for example, a user info endpoint, which you can give it an access token and it'll give you back details about that user, who the access token was issued to. So you could use the refresh token to get a new access token and then go fetch the user details from the user info endpoint. Yep, that makes perfect sense. So also, Tim, if you're having trouble with this, I recommend you check out some of our articles on our developer site. Around Eloth, Erin's written a bunch, Micah's written a bunch, I've written a bunch. We have some really great guides, which will introduce you to the concept of working with these things in real-world applications. So check those out. They should get you started. Just literally Google Octa developer Eloth guide and you will find some of our helpful, useful stuff. All right, so the next question we're going to talk about is from Joshua Wang. So Josh says, we have two completely independent websites. Okay, pretty cool. We plan to integrate them with Octa for logon and identity management. Okay, that's pretty great. Thank you. Shall we have one Octa tenant and two applications to support these two websites? Or is it better to have two separate tenants, one for each website? Keith, I'll let you handle this one. Yeah, it really depends on if you want a single user identity across the board. If you want separate user identities, yeah, two separate instances, that means you'd have different users, different passwords, different MFA policies, different everything across the board. And then on a management side, you'd have two different places to manage everything. I'm not a fan of that approach because it just increases overhead without necessarily a lot of value. I flip it around and say, okay, if they're associated brands, like Albertsons, the grocery store chain is like Safeway and Randalls and everything like that, but it's one brand. You have one tenant that hosts both of those, both websites as separate applications. Now, you've got one view of the user. So now you can say, is this user a customer on both sides? You've got one MFA, or you've got separate MFA policies, but you only have to enroll them once. Like you've got a lot of flexibility there. A lot of abilities to do stuff. So I'd recommend one org, two apps. Just simplify your architecture. I totally agree. It's very dependent on what you're doing, as Keith said, but in general, if you can keep it simple and just have everything in one tenant, don't make things difficult for yourself. So great question. The next question we're going to talk about is from Hugh. So thanks, Hugh. And Hugh says, when edits are made to a user's claims, what is the best way to force their token to refresh? Should the old one be revoked? This is a very difficult question because it really plays into what tokens are used for at a high level, which is really, they're a cached, cryptographically signed blob of JSON data at the end of the day, really. And so they always have an expiration time of some sort, and that's going to determine how long they're used. I think part of the answer is really going back to how are you validating tokens? So for example, if you are building an API service and you are accepting tokens into the API service and you're validating them locally and just checking the cryptographic signature in the expiration time, then there's not necessarily going to be a way you can, you know, force a token to be refreshed because it depends on how it's being validated. If you are conducting something like an introspection request every time you receive a token, if you want to fire off a request to Octa's introspection endpoint to say, hey, is this valid? What are the things in there? That will force a token refresh. And so there's a lot of different strategies you can use there. I'm not sure, Aaron, if you have any other additional commentary to add to that to help you out. Yeah, I talk about this in my workshops all the time. I think, yeah, like you said, the best way to think about these tokens and the claims is that they are a snapshot at the time it was created, which means essentially everything in the token is probably out of date by the time you're reading it. And it's best to just assume that it is stale data and the question is just how old is it? So whatever your token lifetime is determines how old the worst case will be. So if you use one hour tokens, the oldest data that you'll have to be working with is one hour because the tokens will expire, the app will have to get a new one. If you have 24 hour access tokens, then you might be operating on 24 hour old data if you're only reading data in the token. And then the other thing to keep in mind there is if you know you never want to be acting on stale data, then don't ever read the data from the access token. So you might do like a first pass of validation of like is this access token even valid at all which will tell you that you're not dealing with like an attacker, like a bot or whatever, right? And then after that you might say okay, well I don't trust the user's name that's in the token, I want to actually go get the current up-to-date version. So then you might go and do introspection so it's definitely a balancing act because you can't always do one or the other because you would either always be acting on old data or you would always be slow. So it's definitely it's a balancing act. I'm going to add a little bit of extra stuff to this question because it's a very good question I think. People have this like all the time we talk about this a lot. So Aaron, maybe you can give some general rules for the listeners. So if what types of token expiration times should people be general based on the type of application they have. So for example, if you're building a social networking app, how long should your tokens last versus if you're building a banking application? Like what are some just general guidelines so people have some ballpark of what we're talking about here? Sure. So first of all, Okta has a couple of hard limits on token lifetimes that are enforced. So I believe the minute the quickest expiration you can configure is five minutes and the longest expiration you can figure is 24 hours. That's for access tokens. Refresh tokens can be unlimited length because those are not used. Those don't contain any actual data and they're just used to get new access tokens. So within the five minutes or 24 hour range, that's what you're working with as far as the options you get. The thing to keep in mind is that it's all these different you're balancing all these different factors. So for and risk is one of the factors. So the risk of a leak token or the risk of operating on stale data is a factor to consider. So for higher higher risk environments where you're doing more sensitive operations, I would go tune down the knob on your risk exposure. So even within a banking API for example there's tiers of riskiness of API. So you might have a method that returns the list of the user's accounts and the current balances but only the last four of their account number. That's much less risky of an operation than an operation that moves money from one account to another. So if you're going to move money from one account to another, you never ever want to operate on a token that may possibly be stale data. Like at all. So you would always introspect on that operation. But returning the list of user's accounts and the summary of their current balance, it's probably fine if you're working with an hour-long, hour-old data. Because probably no new information has been leaked. So then that's one side, but on the other side of this is the user experience side of the shorter your tokens are, the sort of more interrupted the user is going to be in some way. So it's either going to surface as a refresh which might just add a slight delay to an operation. It might surface as a full login again. And you need to balance that side again with user experience. So for the consumer apps it would be extremely frustrating if Instagram made you login on your phone every day. Users would just not do it. So they skew they're willing to take more risk to provide a better user experience by using longer live tokens. Alright, so some things to think about. Yeah, thanks for the question, Hugh. Alright, next question we're going to talk to is Daniel. So Daniel asked how do you recommend separating your dev QA staging prod environments so you can test changes independently. Do you recommend separate tenants or another approach? I think our general best practice is to have separate tenants for each of those environments. That is going to give you a lot more isolation and hopefully less risk that you mess something up. So we'll just go ahead and mark that one as an answer. Alright, next question we have a question from Igor and Igor asked, can we use the ID token as a user's session ID? So Keith Aaron either of you want to take this one? Can you use the ID token as a session ID? Have you given some presentations on this? Yeah, so in general so I'll just sort of provide slight more context I guess but in general you probably don't want to do that. So the ID token is just a JSON Web token that contains some basic profile information for a user. It's not a token that you would use to like validate someone's identity. That's not what it's for. It's basically like a convenience token where you can without making an API request to a back end grab some basic user information and so the answer is no, the only thing you should use ID token for is to grab basic user information essentially without making an API call. Aaron, am I messing anything up there? Does that sound right to you? I mean I think that there's it's not necessarily bad. Although I don't know how many advantages you really gain from it. So it's very common that most Web frameworks have their own built-in way to do session management so it's probably easier to just use the built-in thing. I guess the one advantage you would get of using an ID token as your session ID is that the lifetime of the ID token is then consistent across everything that's using them as session IDs. So your session lifetime becomes the same as the ID token lifetime which I guess could be a good thing or a bad thing but that's the sort of difference, right? So actually, hold on, maybe I'm misinterpreting his question because I think like let's say you're building Yeah, so this could actually be interpreted a few different ways. So let's just clarify this. So let's say you have a single page application, right? And so you're authenticating to Octa's OpenIDConnect server and you're getting back an access token and an ID token. So you have this access token and ID token now. Well, whenever your front-end application wants to make a request to your resource server to query an API endpoint or do something that requires authentication you can't authenticate using the ID token, you have to use the access token, right? Yeah, and so I think the question it's slightly vaguely written here but if you were to store in whatever session thing that is, whether it's like a server-side app and you have a cookie or whether it's a spa app and you're using local storage you couldn't use that ID token to authenticate yourself to the back-end so therefore you would have to embed in the session when you're making that request the access token itself in order to successfully execute that request. That was the way I had interpreted the question but now that I'm reading this I realize it is pretty big and open for interpretation but Igor hopefully both of those answers give you enough context to understand what we're talking about here and if you want more clarification please ask and I will look for your question in here and try to get back to you. All right so let's see what we got here Alice asks we have a device microservice that has two APIs one that gets device details and one that gets a device's location the device get details API is only accessible internally and the device get location API is only accessible internally and externally we're using client credentials our token is built with a specific client company ID in it to make sure that it is the only access sorry this is written a little weird the token is built with a specific client company ID in it to make sure he only accesses the devices that belong to him. Okay so the token has a client ID in it basically so that they can match up to see what devices someone can use. I wanted to use the scope claim and add only device location to external clients and both device details and device location for internal clients the API checks if the proper value is there to allow the call is this a valid use case of the scope claim I'm just going to go ahead and answer this because I realize as I'm reading this to you guys the context might be difficult but I think the answer is yes so you can use the scope claim to embed permissions in there that you are then going to validate when you receive the token that's probably the best way to do it the only real concern you're going to have is if you have permissions that are changing before the token expires like Aaron was talking about earlier so like if you are frequently updating permissions for these devices and trying to determine whether and it's very important like whether or not someone has permission to do this you're not going to want to trust whatever is in the scope you're going to want to actually reach out to the authorization server validate the token and get back a list of the current scopes at the time the authentication request comes in so that you can then authorize this user properly so there you go all right let's see let me pull this up next question is from Frizzana who asks is there a migration strategy or process in place that can be used to move configuration so that would include applications sign-on policies etc from a dev environment to QA and then to prod or does each environment tenant require manual configuration Keith you want to take this one yeah there's there's actually some work going on on this front to make that process easier the default way is to do it manually which isn't great we also have a Terraform provider that is sort of the level up from there my understanding though is that the way it works is that like however you should use it to also configure the dev environment in the first place in order to be able to diff and clone that environment across the board I haven't worked with the Terraform provider recently though Randall of you played with that or explored that yeah it's pretty good it covers a lot of the things he's asking about there so check out the octa Terraform provider it should get you like 90% of the way if not more and if you do have any problems with it or something's missing please leave a github issue because we are actively developing and maintaining that so we want to make sure it has everything that you need all right so we do listen we do care thanks for the question next question real quick is by Paula who asks hey I need to drop off in 10 minutes will this be recorded and where will the recording be shared Gina I know you are here listening I know this is being recorded the answer is yes it's recorded and I believe Gina if it's okay with you we're going to share this to our octa developer YouTube channel once we are done and that YouTube channel is youtube.com slash octa dev so you can go ahead and check that out later we also have tons of other videos on there of us doing similar things like this so we do these Q&A sessions pretty regularly I'd say around once a week so you should absolutely go subscribe to our YouTube channel and like and all that great stuff so thanks all right next question let's see let's go through the list here all right here's a question excuse me from Peter Peter asks how do I create a test environment that allows me to test sample support in our product interacting with our customers who are using octa as an SSO solution Keith you want to take this one I knew this was coming at me as soon as you said SAML SAML is kind of a it's a challenging tool yeah to be polite it's the bane of my existence at times but no that most likely the way you'd want to set this up is you'd have your production environment a dev environment with some sort of inbound federation to your production environment so that when somebody wanted to log in to the dev environment they could use the production environment and come back to it so you've got a single sign on approach and at that point then you could you should be able to start the login process in your dev environment finish it in production and then pass the results back to your dev environment so that you can act with your app I'd have to check out the configuration to be more specific but I think that's a general pattern that should work for you yeah and if you have any deeper questions there Peter hit us up we'll try to get back to you with more context next question is from Paula I think this is the same Paula who asked to leave so hopefully you will look at this in the recording later but she says hi I have a product that requires our customers to install executable that we provide locally and we expose apis through azure's api management and we want to secure those apis using custom scopes aka custom access tokens minted via octa what is the best flow for those remotely installed executables to retrieve to retrieve and present hold on and present access tokens since there is no human identity involved if the apis were not publicly exposed the client credentials flow we just want to make sure we don't expose the client ID or secret within that executable that is installed at our customers locations Aaron this is a really common question I'll let you take it oh that was so long which one is this I need to read it let me let me read provide the context basically her company builds an executable that her customers install on like a computer and they're trying to figure out in that executable make authenticated requests to their azure api services that power it behind the scenes without embedding a client ID and client secret in the executable itself great yes that is a problem you basically can't ship the executable with a client secret it just well not not possible so the you have to do the actual OAuth flow and get a user to login to that in order to get the access open into that device so this is what this is see I have a blog post on the Octave Developer blog that talks about embedding secrets in mobile apps or native apps so that's a good reference for that talks about this problem and why it's a problem the solution is to do an OAuth flow that does not require a client secret bootstrap it that way so get the user to actually login to it unfortunately you can't actually just ship it I'm gonna go ahead and share my screen real quick by the way too and show you Aaron's blog post he's talking about here so it's called why OAuth api keys and secrets aren't safe in mobile apps so just google this check it out you will find it on our developer blog it's really awesome you just wrote it not too long ago so you can read through and get all the information there's no human identity information human identity involved in this you do have to get a user involved to log in to sort of enroll that device so let me play devil's advocate for a second so what if the apis that Paula is protecting here they don't have any human context or like anything like that and maybe they just want to keep them generally safe but like it's not 100% required would you say that mutual TLS is another potential option here so maybe the application ships with its own SSL certificate that is whitelisted by the server side apis so that they can communicate securely without like someone using Charles proxy intercepting the request traffic and then manipulating it or what have you I mean it's the same same problem at the end of the day like if you ship a certificate in the app someone could decompile the app extract the certificate and use it themselves and there's no real way around that so if you are okay with that being the amount of effort someone has to put into hack the API then use that option if you're willing to take that risk which is slightly better than a publicly exposed api but just know that it is not actually you know secure someone can reverse engineer it but it might just be you know more work than anybody's willing to do to actually reverse engineer it so yeah the unfortunate thing about that is that that's kind of the baseline on what most people do we were working with somebody last year Alyssa Knight she's fantastic hackers hacker type of person she got she downloaded 30 apps from the the Google app store and found that mobile apps I think 29 of them had credentials embedded in them whether that was AWS like s3 read write keys or apis like api keys things like that like read write access to all these different services so Paul I know you're you're struggling with this but that a lot of people are but you need to have some sort of user identity you can't ship secrets in these these apps whether it's mobile native whatever it doesn't matter you just can't do it you're opening yourself up for a world of pain alright well thanks guys the next question is from Bob so Bob asks Samuel 2.0 question here how do you recommend implementing e-signatures we want to challenge the user for their password during an SSO session but we're not sure how to submit the ID and password to a sample endpoint thanks Keith I know Samo is your favorite protocol in the whole universe so like I'm going to let you take this one as well I'm going to respectfully decline this one because honestly I don't have a clue I suspect it be related to like like resetting the sample flow or revoking it whatever but I'm not sure the mechanics yeah so I have basically zero expertise with Samuel except for like how not to use it so unfortunately my input is useless here Aaron how about you nope nope no idea I avoid Samuel at all costs so we have run into the boundaries of where we can answer your questions everyone so we apologize so Bob stumped us all yeah Bob stumped us all do we have to like buy a drink or something or send him a t-shirt or something like that I'm sure we can make something happen Bob if you're still watching this send your address and your t-shirt size to evangelismatOcta.com and we will get you sorted out alright next up we have a question here from Josh alright Josh says let's see this might be a long one oh there we go if we use Octa to support internally facing web applications where the user accounts are stored in Octa and internal web applications where the users are our employees excuse me and we plan to integrate Octa with our active directory to support SSO will the same pricing model apply now I don't know much about our pricing Keith do you know a lot about our pricing like if the internal users are separately than the external users yeah they generally are so the way we look at the world is that there's trade-offs between internal or what we call workforce use cases and customer use cases so the external customer use cases are priced based on volume whether you have a thousand a million users whatever like it varies based on that internal use cases are also based on volume but the number is much smaller because odds are you have a hundred or a thousand customers for every employee that you have that's kind of the sort of thing the capabilities that those employees need are radically different so yeah we vary it based on that and the product the underlying product is the same for both it's the blend of it within that so like for customer identity we might have inbound federation or social authentication and simple second factor like SMS for internal use cases you might issue UB keys to every employee so it's a different sort of workforce and different sort of mindset there fantastic alright next question we have is coming from Greg and Greg asks in a basic OAuth scenario I have an API built in C sharp that receives a token from a client and needs to authorize it against an identity server okay so it sounds like a use case for the token introspection flow already I'm wondering if the API needs to be passing in credentials in order to validate that token is authorized against a particular scope whoops it's really hard to read the questions on here because the box is super tiny sorry and if those credentials from the API should have some permission scope to allow it to get that authorization response I hope that makes sense mmm that does not make a lot of sense to me let me read this so I think I know I think I get it oh you got it I think the question I think I get it I think the question is whether the act of validating the token should be itself an authenticated API call right which is how introspection yeah so if you if you have an endpoint that's going to be validating the token then do you want to put credentials on that endpoint is that a good summary of the question I think so and also I'm just going to go ahead and pull this up if you haven't looked at this yet Greg we have a guide for validating access tokens on our website so if you google octa validate access tokens you'll find this and it talks about how the introspection request works and it has all the information in here including what parameters you have to pass in for example your client ID your client secret if you need that there's like a bunch of different things in here you can look at too you might just want to check this out but Aaron did you have any other context to provide for Greg no I think that's a great place to go that document talks a lot about all the different considerations there well I think there's two different layers the access token here I think the way it initially describes is that the access token is opaque like there's nothing actually in it submitted and blown up into actual scopes and claims and things like that that validation stuff is there you can do that lots of APIs have that where the actual API key or token is just a big opaque string with us you can also have access tokens that actually have stuff in them so you can have the scopes in them so you can validate that access token locally or hit the introspection point get a result caveated by what Aaron said earlier that access token is a snapshot in time so make sure that you can trust that window that snapshot within when you actually need to take action on it that makes sense all right it looks like Tim has another question Tim asked a refresh token question earlier so he has a follow up to this is it bad practice to validate a refresh token against your octa authorization server to see if that token and the user is still valid so he's talking specifically about refresh tokens here now correct me if I'm wrong you guys but there's not really any benefit to introspecting a refresh token because when you use a refresh token whenever that is at some point in the future you're going to send it to octa anyways to get a new access token and at that time it will be invalidated like it won't be valid if it's if it's been revoked or whatever it is so in I can't really think of a good scenario in which you would want to validate a refresh token using introspection Aaron Keith can you guys well I would rephrase this you shouldn't think about this as validating refresh tokens you should think of it as using a refresh token the act of sending the refresh token to octa is using it to get a new access token and then octa is creating a new access token at that point as well as doing whatever else is associated back in the chain of like keeping track of the fact that the user has a new access token and things like that it is not validating the refresh token it is using it, redeeming it so if you think of it that way then then the question becomes is it bad practice to use a refresh token to check if the user is still valid and I think that starts to sound weirder right that seems like that raises more flags to me than the way you phrased it which was validating a refresh token because you're not validating it you're actually using it yeah that makes sense alright next question is coming from Ethan so Ethan asks we are trying to integrate with octa so our customers can do SSO and their customers by the way are already octa customers so cool it sounds like we're going to be using OpenID connector rather than SAML yay that is fantastic don't use SAML unless you have to your docs say that we need to know the client ID and org URL is this org URL our octa dev server's org URL or do we need the org URL of our common customer and to be honest I think it actually depends on specifically what you're doing here because the org that you're talking about that org URL is going to be for the authorization server and so in your case it says you're trying to integrate with octa so that your customer can do SSO and so if they're SSOing if they're using their native credentials to SSO into you then it's going to be their authorization server that you have to talk to but if it's the other way around and you are going to be the root holder of the credentials it's going to be your authorization server in your org URL hopefully that makes sense I realize that is a complicated scenario there but hopefully that phrasing will help you change up a level it comes down to who do you trust do you have to trust them or do they have to trust you if you have to trust them when you get that inbound token you need to know you need to have a prior trust relationship set up to be able to say okay I trust tokens from this org from this octa URL now whether that is your dev server their dev server or whatever doesn't matter it's which direction does the trust have to flow if you need to trust them you need to know them in advance yeah I think that's a great way to put it thanks Keith alright next question is from Joshua he asks can we configure our password policy to enforce newly registered users obey a new password policy while still allowing existing users to log on with passwords which do not match the new password policy the answer is yes so when you're using a password policy in octa it applies when people are changing their password or setting a new password it doesn't apply to existing passwords and if you think about it that actually makes a lot of sense because octa is not going to store the plain text version of someone's password like we hash the passwords using industry standard best practices and so we actually don't know what the password is and we're not going to for example like when someone authenticates using a bad password we're not going to look at the plain text version and say oh this is invalid like refresh or anything like that we will hash it do the comparison get it out of memory really quickly so the answer is yes that is the the only way that it works alright let's pull up the next one here so let's see let's see oh that question is not fully completed yet so we'll wait for them to finish typing that one in okay here we go next question is from forzana who asks is there a way to set different logging levels in octa for example can we restrict the view of the system log for different users by debug info warning etc that's a great question Keith Aaron either view have any input on that because I'm honestly not sure no I don't believe we make that distinction at all what we generally recommend for logging is that you plug something into it like a like a splunk and then you can do the filtering on that layer so we only keep the last 90 days and we don't do anything along those lines great alright thanks thanks for the question forzana the next question let me just read this because it's written in two different questions on here okay so this one says I'm not a developer but I'm studying for passing one of the octa's certification exams and I can't find or I can find many example sample apps but not many open id connect example apps do you have examples which use open id connect yes so we have a time so what you can do is go to actually let me just pull it up real quick I'll share my screen real fast to help you out so you can go to our github organization it's github.com slash octa developer so we have hundreds of example applications on here that you can go and look through and also go to toolkit.octa.com which has lots of different applications that we've built almost all of these are using open id connect and you can look at the code and see how they work you can even deploy a lot of them with one click you can do all sorts of things here and then finally if you go to our website our developer website developer.octa.com and click on the blog you can also go through here and read our blog post which almost all of them talk about open id connect and a lot of things like that and so there's tons of things in here you can look at and learn about to see how an open id connect application is built so hopefully that helps you and good luck with your octa certification exam actually that reminds me Keith you recently helped build a new certification exam for developers didn't you? yeah we just finished that recently so tell people about that because I know it's brand new so someone might be interested in checking that out getting octa certified etc yeah so we've had like the octa basics and the administrator and like the consultant certifications for years but what we started working on were probably a year or so ago by now was being able to say okay you know how to use octa from the dashboard let's make sure you understand how to plug in how you integrate with it how you build custom apps around it so it gets into the mechanics of handling tokens how do you make sure you do that handling API calls things like that it doesn't get into like individual versions of SDKs and things like that that's super specific and not really fair if you don't work in that language but we really want to make sure that as you're building applications that you're building it building it smartly you're building it securely that you're protecting your customers as much as we want you to so I also just pulled up some information on this real quick just in case any of you are interested in getting octa certified but the new certified developer program I'm just reading some stats about it so there's no prerequisite exams you have to go through to do this one it's a two part exam part one is a 60 minute discrete option multiple choice test the second part is for performance based use cases and there's a really cool performance based app that you get to use to play around with it that one of our other coworkers actually built which is pretty great and it's going to be $250 and that goes live August 3rd so pretty soon a couple weeks from now and if you want to sign up for that it looks like the right place to go to is this right here just share my screen it's octa.com slash services slash certification so go here August 3rd check it out if you do want to get octa developer certified and give us feedback on what you think so there you go great question alright let's see what we got next here moments we have another follow up question about that password policy question from earlier so can we force existing users whose passwords don't match the new policy when the user logs on so I'm trying to phrase this right I think what they're asking is if we have a password policy and it's very strict and someone who already has an existing password is logging in can we force them to change that password Keith can we do that I believe there's a couple different strategies the easiest one is you use an API or the dashboard and put them into an expired password state and then the next time they log in successfully including whatever MFA required once they've successfully logged in they'll be requested to change their password so that's a quick do it without sort of without interrupting them or preventing them from logging in next time around alright fantastic next we have a couple questions from Nilesh hopefully I'm saying that right Nilesh asks and I'll just go through these one at a time so it's not too confusing so first question there's octave support SSO and any SSO mechanism between a native mobile app and a web application our website is using OIDC an OIDC API and our mobile application is using the octave native mobile SDK so they want to know do we support SSO between the mobile app and the website so if you're using the octa mobile SDK that's built on the app off library from the open ID foundation which uses the shared session cookie storage between that and whatever the native browser is so assuming you're using that then as soon as you log in through the mobile app you should also have a session within your browser itself so yes you would be logged in at that point let's see I believe that's the baseline in iOS, Android and I think there's some Java script support for it I'm not familiar with that side Aaron did I get that right yeah cool so the follow-up question Nilesh has is what is the recommended implementation between a native mobile app and a web application like how do you handle I guess those authentication and authorization things together any supporting or example documentation references would help I can share my screen and just pull up some things for you real quick but we have a lot of documentation and blog posts really that we'll walk you through so if I just Google Okta developer documentation let me share my screen so sign users into your mobile app this is one of our Android guides we have a blog post from a couple years back talking about using OAuth 2 and native mobile apps we have guides talking about how to sign into a mobile application using Okta so just Google Okta developer mobile application that should we can get some help real quick so hopefully that's that's useful right markdown is answered it looks like there's a follow-up question here let's take that's actually a question about our dev form stuff so I'll leave that off until later what else do we have Keith do you have any familiarity with work days ecosystem I'm gonna go ahead and read the question but I am not at all familiar with work day so I have no idea but the question states within the work day ecosystem we have some use cases where we have built-in support for OAuth API access okay sound good so far a lot of times the client uses Okta for SSO and they may have partner applications that are integrated with Okta and have a need to pull employee data from work day with more and more people moving towards work day if we're going on a daily basis on user sessions are there any plans to make SAML bear token integrations easier like what you have done with worker provisioning in work day do you already have the documentation around it again I have no idea anything about work day Keith do you I know it exists and that's about it I got nothing I'm sorry all right capo lesh I am sorry best to sort you out. But yeah, we have no idea. The three of us are basically developers who work in the security space. And so we will try our best, but that answer eludes us. So we're sorry. All right, next question. And it looks like we've got seven minutes left. So let's see if we can finish these last couple real fast. So this one's from Greg. Greg asks, follow up to my authorization question. Our customer has their identity server setup so that at this point in development, the client ID and secret my API is configured with to get the authorization has to be the same as a client ID and client secret of the access token being sent, which sounds wrong to me. This was the basis of my initial question. How should the API be configured regarding client ID and client secret? Meaning should it have its own credentials configured on the identity server and be passing them? Aaron, would you care to take this one? Yeah, there was a lot there again. Let me read this again. The one thing that I was confused about was what it means when you said the same client ID and secret of the access token being sent. So access tokens don't have client IDs and client secrets. Client secrets can be used to get an access token, but they're completely different things and they're not associated. So, but the actual question is, should this have its own credentials at the end? Yeah, so like you wouldn't want to have the same client secret in two different like identities of reservoir servers. That seems weird. I would, that's a password, right? And like you shouldn't be reusing passwords, which is essentially what that is. So yeah, every component should be having its own client secret and you treat it like a password and you only send that to the place that it came from as a way to prove who you are. Great, all right, I think we have time for just about one more question here. There's a question submitted anonymously leading up to this which basically said, how do I maintain two copies of user data both on-prem and within Okta? And it's a really good question. It comes up quite a bit. I'm gonna provide a little context. Keith Aaron, feel free to jump in. But let's say you're building in a traditional web application, right? Like a bookstore, an online bookstore. And so you have a relational database like Postgres where you store all of your user information maybe and then you have Okta and you're integrating with Okta. Well, ideally what you're gonna do is you're gonna migrate those users out of Postgres and into Okta, okay? And when you do that, it leaves this question behind that a lot of people struggle with, which is in my relational database, I had all these objects that were tied to my users via like a foreign key relationship. So maybe in the past you had like a book table in your database that was related to a user's table in your database because a user purchased this book or maybe they wrote this book or whatever it is. And now you're trying to figure out, well, how do I relate something to a piece of data that's no longer in my database ever? And basically what you need to sort of wrap your mind around here is you wanna use your Okta user's unique HREF, like it's a URI that uniquely identifies it as your identifier in your actual database. So in Postgres, for example, instead of having like a user's table, in your books table, you would have a column for user underscore HREF, let's say. And that would point to the Okta user HREF. That way, when you wanna get the user associated with a book, you query the books table, you get the user HREF field out of it, and then you use one of our SDKs, you pass in that HREF and say, hey, I would like to retrieve this object, please. And it will get the user so that you can then grab their information. Now, if you really wanna go out of your way to keep duplicate copies of the information, so have Okta be the central source of truth for your users, and then also store a duplicate copy of that information in your own database server, you can totally do that. It's just, you're probably gonna have to plug in to some of our webhook calls to see when users are created and updated. There's like some webhooks you can tap into there. If you Google Okta hooks API, you will see all the documentation in the world which talks about those things. Or alternatively, you could always write some sort of chron style script that will hang Okta's API, look at all the users once over every time period, and then ensure that all of those have been copied into your local database. But in general, I wouldn't recommend that because it's a lot of hassle, you don't really get a lot of benefit. I would just try to instead wrap my mind around using the user href field and using that for relationships. So hopefully that answers your question. And let's see. Well, we have two minutes left. Let's see if I can find a real easy one here. How much more will be worked on when it comes to the Okta app? I'm assuming they mean our Okta, like actual mobile application. And we have a whole team of people that's working on that application. So I think it's safe to say that there's lots of stuff coming down the pipeline. I don't know if any of us has the exact information on that, because that's not really our area of expertise. But don't worry, those things are constantly being updated. So I'm sure there's a lot more. And let's see what else we got. Final question, we'll do this. What are you looking forward to seeing released that you have been working on? So Dustin asked us this question. So Keith, why don't you go first? What are you looking forward to that you've been working on? Oh, the identity engine. Sort of refactoring and cleaning things up and restructuring things from the ground up is really cool. Watching customers eyes light up when they're like, wait, we could do that? It's kind of badass. Aaron, how about you? Let's see. lately I've been working on actually building out a, or rather updating a WordPress plugin that I wrote a while ago for integrating octa using octa as your WordPress login. And it's not officially supported product at all. It's just something I put up on our GitHub. And it turns out a lot of people have been using it. And so working on some updates, fixing a few bugs, but it's pretty cool seeing everybody using it. And I know for me, I've been working with quite a few other teams here on revamping some of our developer SDKs, which is something I'm personally really excited about. In particular, our Python and Flask SDKs, because I'm a huge Pythonista, look for a new Python SDK coming out in the very near future. So if you check out GitHub, you can actually see the work in progress that's been going on there. It's super exciting. And if you're a Python developer, obviously I think that's a big deal and it's gonna be pretty cool. So I think that's literally all the time we have. So it's been exactly in our absolutely full of answering questions. So thank all of you for coming and joining us. Aaron, thank you a lot for all of your expertise in helping out Keith. Thank you a bunch as well. And would either of you like to say any final parting words before we get the heck out of here? Nope. No? All right. Well, I will just go ahead and plug stuff for you. Check out Keith Casey's book. I believe we have the link in here. It's a really great book on building APIs. Also, please check out Aaron's book on building OAuth applications. It is the definitive reference on the subject. It is absolutely fantastic. Keith, give us the URL for your book. Aaron, then please give us your URL for your book and we'll be out of here. Yeah, mine's really easy. It's theapidesignbook.com. Not some API design book or another one, theapidesignbook.com. Great. And then Aaron? Cool. Mine's also really easy. It's OAuth.wtf. There you go. All right. Thank you, everyone, for joining us and we will catch you next time. All right. Take care.