 Hello and welcome to another one of our Octa Office Hour sessions. I'm Randall, I'm going to be your host today. For those of you who don't know me already, I am a developer advocate here at Octa. I currently lead our Developer Advocacy Group and my background is in web security, cryptography, building and scaling large applications. So I'm more than happy to talk about any of those things. And I'm joined by two of my absolutely amazing colleagues. So first off, we have Aaron Perrecchi. Aaron is one of the authors of the OAuth 2 protocol. He's super active in the web security community. He works on a project called IndieWeb, which I will let him talk about in a moment because I think it's fascinating and he's a great person. Aaron, do you want to give the audience a little more context by yourself? Sure. Hi, I'm Aaron. Nice to be here. And yeah, I am heavily involved in the OAuth working group writing the specs and helping move that work forward as well as the IndieWeb community, which is all about data ownership and online privacy, online identity, something that is clearly becoming very important these days. And it's been a lot of fun to have that community going as well, helping people own their data and have a web presence that does not rely on things like Twitter. So yeah, I just really enjoy doing things around security and online privacy. Thanks, Aaron. And then next we have Micah Silverman. Micah is an absolutely incredible programmer. He's been active in the web security space for many years now. He's a pro on basically everything. Micah, you want to give a little more information about yourself to the audience? Yeah, sure. So Micah Silverman, like Rangel said, and I'm kind of like a jack of all trades, maybe master of none. But my title here is Staff Security Hacker. I like to break things and then hopefully fix them. And I spend a lot of time writing everything from proofs of concept to fully blown production code that's in use both internally and externally with good security all around it. Awesome. So today we're going to be answering all of your questions live. So if you do have questions, please drop them into the chat room. I'll be going through and selecting them. And if you need further clarification or follow up afterwards, just respond in the chat. And I will do my absolute best to make sure we have that. It looks like we had a question come in already. So the first question is from Ryan. So thanks, Ryan. And his question says, we have an application that sits behind an SSL VPN. It has different URLs for both internal and external access. We set up a SAML template app to access it internally using the internal SSO. Okay. I don't see the question there, Ryan. Add some more context and we'll get back to that one, okay? In the meantime, we do have some other questions so we'll jump to that. So Benjamin asks, what is the best method for keeping your API tokens secure? Now, this question is a little vague, Benjamin. So I'm going to break it up into a few sections that we'll answer for you. So first of all, Aaron, let's talk about what people can do to keep their API token secure in the browser. So let's say for a moment that someone has a web app using the off-code flow with Pixi and so they're getting a token in a browser-based application like React or Angular or Vue, something like that. What can that developer do on the client side to help keep that token secure? Yeah. So I guess there's two parts to this. There's the part where you get the token and then after you get the token, how do you make sure you keep it secure? Keeping the token secure when you are getting the token is going to be primarily by using the authorization code flow with Pixi and Pixi is a mechanism that will protect that flow and make sure the token is delivered in a secure way in contrast to the implicit flow where the token is delivered in a not very secure way. So that's the first part. Second part of that is after you have the token, where do you keep it? And this is where I guess a little bit messy in browsers. There isn't actually a very good solution. The best you can kind of do is put it somewhere where your app can reach it. And wherever your app can reach it, the downside is any attackers who can run cross-site scripting vulnerabilities on your app can also reach it. So it doesn't really matter in the end whether your app is storing in a cookie or local storage or session storage or whatever because those all are vulnerable to the same cross-site scripting vulnerability possibility. If you want to make sure that that's not a possibility, you have basically two options. One, don't put tokens in the browser in the first place. Move it all to the server side. If that's not an option, there's a sort of clever workaround for this using a service worker in the browser. And a service worker is it's kind of like a little isolated place where code can run that the browser DOM does not have access to, which means it actually can be used to store tokens there. It takes a bit of work to set that up. There's some other downsides there as well. But that's a pattern that's a possibility for keeping tokens there instead of just in the regular browser DOM. Okay, so Micah, I'm going to let you handle the second part. So because Benjamin's question was a little vague, let's also take into account what if he meant that he has the Okta SSWS tokens, like the Okta API key that he's using to access the Okta API to make requests for the management things like creating users, doing things like that. Is there any particular advice you have for him around keeping that type of a token secure? Yeah, it's a great question. And the short story is that type of token, that fixed, unchanging API token, can never be in something like a spy app. It's just not, excuse me, it's just not safe to have it there because people will pull it out. And once that's leaked, it gives you access to everything in Okta. So first step is you just have to have middleware in this case. Your spy app will work just fine. You just have to communicate with some .NET or Spring or Node.js or some kind of middleware. So then the question is, well, on my middleware, let's say I've deployed it to Heroku or Azure or whatever. How do I keep that API token safe there? And there's a lot of different techniques. Kind of the lowest bar is as an environment variable. So you don't ever want to have it hard-coded in your code anywhere. You definitely don't want to have it living on GitHub. Those are mistakes that we have lots of reference points that people have made. And again, once that API token is leaked, it's kind of game over. So at least as an environment variable, and the different frameworks have different ways to pull in properties and things like that, but you want to keep it completely separate from your code base. And then you can get into more sophisticated approaches like storing it in a key management service like AWS. Amazon has KMS for key management. It just gives you an extra layer of security if somehow your deployment environment were compromised in some way. Maybe the key to that API token won't be leaked even in that event if you're using something more sophisticated. For proofs of concept and hobby projects and things like that, I use Heroku a lot, and I just have it stored as an environment variable never anywhere near the code. That's safe enough in those cases. Awesome. All right. Well, Benjamin, hopefully that answers your question. If you do want to know about some specific API token security stuff, please respond in here and let me know, and we'll go in more depth. All right. Next, let's take a question from Anna. So Anna asked a question a couple of minutes ago. She said, hey, I'm new to Okta, and I want to ask if you have any information or samples that showcase using or building like an ASP.NET MVC application and integrating it with Okta using OpenID Connect and SAML for SSO. So Anna, yes, we do have a bunch of those. I'm going to share my screen right now just to show you how to find them because there are quite a few. So if I share my screen for a moment here, I think you should be able to see it now. Keep me honest. There we go. Okay. But what you can do is go to our developer site. All right. It's developer.okta.com. Click on docs up at the top, and then click on .net here if you're looking for .net apps. So we have official sample apps here. Then we also have a bunch of blog posts that walk you through doing things linked down here. And we have the official sample apps. There's a bunch. They show you how to do things in a bunch of different ways. So you can check those out. And our blog posts are really great if you want more in-depth information about like how to actually build stuff. So play around here. If you do have other things you're looking for, what you can do is literally search like developer.okta.com plus .net. And you will find tons and tons of information and sample apps that we have on there. So hopefully that helps you out. And yeah, let me know if you need any more info there. All right. So next question, let's see one second here. This admin panel is a little slow today. All right. Okay. So next question is by Veronica. So Veronica says, okay. Enter submits the form she says. All right. Multiple partners will be accessing our Okta secured app. And they all have different identity providers. Okay. That's like pretty common. Besides spinning up a new Okta instance for each partner, how could we provide access to each partner's users? Micah, do you want to care to take that one? So each of their partners has different identity providers. And they don't want to spin up a new Okta instance for every single partner. So how do they easily provide access to all those users? Yeah. So Okta has a pretty rich external identity provider connectors, a bunch of them. So if it's using some sort of standard, if these external identity providers are using some sort of standard, like SAML or OpenID Connect, those are the most common ones. But we also have other connectors in Okta's integration network. Then you set up Okta as kind of a proxy in between. So the experience for your users is that they would authenticate in the usual way, let's say through Salesforce or something. And then they would have a presence in your Okta org. But how they got there, you would see on the user in Okta that it was an IDP connected, an identity provider connected user account in that case. So you can partition up those communities of users in whatever way makes sense. You might set up a rule so that people coming in from Salesforce automatically are assigned to a particular group. And then maybe that group is assigned to a particular application. So you can have multiple applications in Okta and you can partition up your users in various different ways. But if it's one big application and you just need to know where they came from, you have all that information from their profile based on how they connected to Okta in the first place. And in a lot of cases, we can automatically link different ways that people have connected. Usually it's done on email, but if you have some kind of common glue that identifies a user uniquely, then you can link up the different accounts. So even though they may have logged in from Google one day and Salesforce another day, Okta knows that that's all still the same user and treats that as one identity. Does that make sense? I think that's a pretty good answer. Let us know if you need more clarification there and we'll dive more into it, okay? Great. Also, Lance just submitted a comment. He said, Micah, I recently watched your push pull authentication video. It was very helpful. Thank you. So shout out to Micah and thanks, thanks Lance. Hooray. All right, let's pull up the next question here. There's quite a few today. Lots of stuff. Okay, so Brian writes, I'm trying to do a quick proof of concept for provisioning and deprovisioning using event hooks with the developer environment and I'm getting stuck here. And he, hold on, he links out to the verification request. That request does not seem to return what is stated in the docs, the X Okta verification challenge. I want to make sure it's still a valid option and I'm looking at the correct things to get a POC done. Hey Brian, what I'm going to do is I'm actually going to copy this URL that you sent over here because it's going to take a while to debug that live, especially if you're not getting the responses that are documented there. And we can look at that afterwards and send you an email when we have time to play around with it. If you want to submit another comment on here with your email address, I'll get back to you with that afterwards, okay? And thanks, and sorry, sorry you're running into problems by the way. All right, let's see, what's the next question? All right, I had a query on step up authentication. What is it and how does Okta support it? All right, so there's more to the question but let's pause there for a moment to talk about what is step up authentication? And this is from Jamie by the way. So Jamie, step up authentication, what that means is, think of it like this. Let's say you're logging into GitHub, right? So you're working on a project. Well, when you first log into GitHub, you're going to be prompted for your email and your password and maybe multi-factor, okay? And so you log into GitHub, you authenticate with an SMS factor or using push base, you know, MFA or whatever it is, your Ubiqui device. And you're in GitHub. And you're going through and you're doing things and you're still logged in and it's fine. But what happens if you go to your GitHub account settings and you try to do something really sensitive, like change your password? Well, what you'll notice when you go to do that in GitHub is when you click like, I want to change my password, GitHub will ask you for your original password again and force you to do another MFA to make sure that it's actually you. And this is called step up authentication. It's basically when someone's already logged into your product, excuse me, but you make them authenticate again before they do something sensitive, just to 100% make sure that this is actually the person that you think they are before they do this like potentially destructive operation. So imagine I'm at Starbucks and logged into my GitHub account, I go to buy a coffee and someone takes my laptop and tries to change my password. Well, they wouldn't be able to because of step up authentication. And so step up authentication is like really nice. We actually have some guides for this, by the way. So if I, I'll pull it up right now over to talk.com plus step up application one second. Ah, here we go. So we actually have a couple articles on our website that show you how to, trying to pull it up right now in the screen share. One step up. So I'll link to that in a moment. I'm trying to pull it up here. So let me read the second part of the question. There's some documentation in the authentic API where they mentioned service provider and identity provider initiated step up off. But I'm unsure of the use cases where it would be used. So yes, to answer your question, you want to do it in your product before a sensitive operation. If I was building a banking website, I would definitely enforce step up authentication before someone transfers more than like $10,000, let's say or something like that or some it's a wire transfer or something. And yeah, if I share my screen real quick, if you just Google developer.octa.com plus step up off, you can find the stuff I'm showing on here. But there's some docs in our help center and there's some blogs you can click through and actually like read here. So give that a shot and let us know if you have other questions. So thanks, Jamie. All right, next question. Let's see. Okay. Lou asks, I haven't been able to figure out a way in the Octa API to do filtering on the server side so that only a subset of data can be returned from the API. Is there something I am missing? If you are calling for a lot of data, it slows things down not being able to do server side filtering. So Lou, you can like perform search queries in the Octa API. Like for example, if you want to list users, you don't have to like hit the user's endpoint and paginate through every user. You can like narrow it down based on particular fields and things. I think what you should do is check that out. If you look at, let me pull this up. I'll share my screen again real fast. If you go to our docs and go to our API reference information or is API overview? I thought I was just on there. Yeah, there's a section on filtering here that you're going to want to read. So go to the docs reference overview and scroll down to where it says filtering. And this will help you, you know, narrow things down so you're not just paginating through millions of records potentially. So give that a go. Let me know if you want more specific information. All right. So next question. Let's see. Hey Randall, just to add to that last point, the postman collections can help you kind of prototype that out. We have a bunch of collections for the management API for creating but also for searching and you can play around with those filtering parameters right in postman if you want to see the results and play around with different filters. Absolutely. That's a good point, Micah. Thanks. All right. Next question is from, I hope I'm saying this right, Jalant. And Jalant says, which is the easiest way of managing credentials stored inside of an on-premise database? So I'm not sure if this is necessarily a migration to author question. I think it is. But let's assume that what they mean by this is they have a database where they have usernames and password hashes that they're doing custom authentication for today and they want to move into Okta. What's the best way for Okta to take over these credentials and manage them? Micah, you want to take that one? Yeah. We recently updated and published a migration guide that goes through a bunch of different scenarios which I'll share in just a second. But there's a fixed number of approaches and ways to do it. The best way, or I should say the easiest way, is if you have access to those hashes and they're in a format that Okta can ingest, then you can just hit an API endpoint and migrate all of your users in one shot. And it might be the kind of thing that you do over a weekend. Maybe you'd have a very small window of downtime just so people didn't mess around with their credentials while you were doing it. But you can do it all in one shot. And then the other probably most frequently done way is let's say you don't have access to that but you still have some on-prem authentication system. Well, what we have to do is create a little shim software that allows you to authenticate to your current system and you have that little window of opportunity where you've captured the plain text password and verified that it's valid through your existing system. And then at that point you create an Okta user and you set the credential because you know it for that very brief window. And then that individual user is considered migrated and typically you would run a program for some set amount of time say 60 days. And over that time some large percentage of your active users would be migrated over to Okta and then kind of as a final step you would cut over to Okta and for that let's say 10% of users that weren't active or didn't authenticate you would send them all like a bulk password reset email which you can also do through the Okta API and then you'd catch some percentage of those of those stragglers but at that point you could kind of decommission your legacy system because everything would be migrated over to Okta. There's a couple of other techniques and things in between but those are kind of the most frequent or the most popular ways to migrate data, migrate authentication and profiles and such over to Okta. And I think yeah go ahead and continue. I'm going to find that migration guide reference and then I'll just post it in the chat or share my screen for a sec. Yeah actually if you pull that up why don't you share your screen for a moment but I know just to help Jelanta out later if you're looking for it just Google developer.okta.com plus migration and you should be able to find that pretty easily. We have a couple guys that walk you through this. Let me, you know I've lost my window. Here we go. Let me share my screen here. Here we go. Sorry it's a little slow. So are you seeing my screen now? Yep. Okay cool. Yeah so if you go to guides there's this migration guide and it starts with a bunch of prerequisites and it goes through basically what I just described and the one thing that I didn't touch on that's worth saying because it's relatively new is what I described was kind of a very manual way of syncing passwords. We now have this inline password hook that makes it a lot easier and basically you would create all of your users in Okta without passwords and then you could use an inline password hook to query the old system and set the password in Okta kind of on the fly. So it's actually evolved over the years now and it doesn't have to be quite as much manual labor anymore. Great well Jelon hopefully that helps you out. I'm going to move right along. There's a lot of questions today. We're doing our best to get to all of them so we'll try to get through as many as we can. So Ryan had a few questions as well. Ryan said hey are there any new features on the roadmap for admins? Are there any new features on the roadmap for end users? Are there going to be any changes or improvements to our CM connectors? So to answer your question Ryan the answer is yes. There is a lot of things planned. We are not allowed to talk about specifics of that unfortunately but one thing you can do which I would recommend all of you do so this is going to be relevant to anyone who wants to see the new stuff coming out is go to octane21.com. This is our conference we run every year. This year in 2021 it's April 6th through the 8th and it's free and it's online. You can attend. It doesn't cost any money and it's super amazing. We have tons of great talks there. We announced all the new stuff for the year so we'll show you all the new things we've been working on all the cool changes to the products that we have. So definitely register for this if you aren't already because this is going to answer almost all of your roadmap questions. I mean it looks like Ann you also had a question about is there a roadmap for a workstation MFA client so you should come here and check out the MFA sessions as well. I think you'll be happy with some of those. There's a few other roadmap questions in here as well I won't go through all of them but check out octane. We will talk about everything then I promise. And sorry I can't give you more information right now I feel terribly guilty about that. Okay here's a question for you Erin. So Ken asks as I'm building additional applications using octa should I be migrating more of them to OIDC than SAML and why? Do you want to talk a little bit about that? Yeah it's a great question. I am definitely in favor of migrating everything into OpenID Connect over SAML at this point. SAML is essentially a legacy spec it works fine for what it does but all of the sort of new stuff and new work in the spec development world is happening in OpenID Connect so it's much more future proof for making sure that you're going to be able to support more things in the future. There's also the that's also where like the security fixes to the actual spec are being made so SAML is kind of just frozen in time whereas OIDC is being updated and is getting best practices are being you know ruled out and then products get updated to match and I would I would 100% go that direction that's definitely where the future is heading. Fantastic one other thing I'll just mention briefly too if you if you want to look up some of the reasons why like OIDC and SAML are are sort of the way they are and why you may not want to use SAML for stuff Google developer doctor.com plus SAML we have written a few articles where we go in depth and talk about like hey like here's some SAML vulnerabilities that are common and here's things you might want to avoid so you know one of the big parts too is like SAML is a much older protocol and OIDC is way nicer thanks in part to the work that people like Aaron have done to just make it much smoother and just generally more secure for people so you know definitely check it out if you're not already using it. I think it's also worth noting that SAML is like OIDC and that it's great for SSO but it's really not suitable for things like your securing your back-end APIs that's not what it was ever intended for and when you have OpenID Connect because it rides on top of OAuth you kind of get that for free so OIDC gives you the ID token but if you're using one of the standard flows you can also get an access token and then you can start interacting with back-end APIs so it's kind of one stack to manage the kind of authentication and authorization needs you'd have in a modern app if you start out with SAML and then you have a back-end API you're probably going to be doing some sort of OAuth flow anyway and now you have kind of two technologies in your stack so you get all that you know in one shot with OpenID Connect and OAuth. Fantastic. All right next question, Jamie had a follow-up from before they said hey regarding the step-up OAuth question from last time is the user forced to complete primary OAuth again or just like verify a factor and the answer is it could be either so it's really up to you how you want to handle that. Neither one is wrong so whatever way you prefer. I think just generally it makes more sense to go through the entire process like at least verifying the primary factor once again because you know you want to make sure that the person has access to a password because that's going to cover the physical case the most but either one of those things is honestly fine. You've probably you know people that are with us today have probably experienced step-up authentication and maybe didn't even realize it. I see it most frequently on Amazon where I can I'm in an authenticated state I can browse around I can add things to my card I might even be able to check out my card but if I want to go look at previous orders or change my credit card info it then asked me to put my password in just to verify that you know I really am who I say I am and not just do something you know like switch a credit card or or you know look at previous orders or something. Yep all right let's move on to the next question so Clarence we're gonna get to yours next. Clarence had a question about progressive profiling and Clarence says hey are there any docs for enabling progressive profiling for your user profiles basically incrementally requesting profile information so let me answer like this the Octa API allows you to retrieve the profile information in a single HTTP request so you can't break that up however using the Octa identity engine which is like a relatively new feature that we have you can do progressive profiling so if you google like I just pulled this up right now we have a few things on our website to talk about this in more detail there's a screen share so we talk about how to do progressive profiling here this is like the press release but the more like useful stuff is here so one of our other developer advocates Joelle who's absolutely amazing wrote an article about configuring progressive profile for your apps so if you just look up like octa plus progressive profiling you'll find this this will actually walk you through the exact steps you need to take to do this in a in an app that you're building so Clarence please check this out and if you do have questions let us know so we can get you like specific information to help with that stuff um all right next uh let's see let's see uh okay jahai asked a question Aaron Micah either one of you can take this how can I deal with the expiration of my aws session token in my code so this isn't really an octa specific question um which is fine but like let's just assume what they mean by this is how do you handle it when you have a token that's expiring in your your application like what do you do maybe Aaron you could start off yeah I guess there's two different ways to handle it so if you're using oauth first of all then that's there's a mechanism called the refresh token and the idea with the refresh token is that is a way for your application to get a new access token without involving the user again so behind the scenes usually from your server side code you can also work from from a mobile app or javascript app that application can just go ahead and make an api request using the refresh token getting a new access token and the user will never see anything and it'll just carry on if you don't have that option then usually the only other way to do it is to actually basically start from scratch you start the flow over again and you redirect the user out to the oauth server now the user may or may not actually get prompted to log in again that's going to depend on the oauth server that's going to depend on how it's set up and lifetimes and other considerations there so it may actually be very quick to redirect out and back and they may not notice it happening but it will be a full redirect to go to the oauth server and back whoops i was muted fantastic all right thanks and i think that's going to be helpful for them um all right let's see uh next question on here oh one of the earlier questions was uh fully written in so ryan we're coming back to you we did not forget about you so ryan says hey i have an application that lives behind the vpn uh which is happening over ssl or tls it has different urls for both internal and external access this app they set up a sample template using the internal sso url for internal access whoops and the application only allows a single identity provider we want to have users single sign on into the app from outside of the vpn we need to use a second external sso url when signing in from off network is there a way to create a custom app that has two different sso urls and can pick the right one for both on network and off network access i'm actually not really sure about this uh micah and do either of you have an idea of of how to configure that with an octave uh the the only thing that comes to mind is um potentially taking advantage of some of the like discovery stuff that we have um that's typically in the context of identity provider discovery this this may not exactly be that but if it's you know usually it's something like uh based on the email address they put in that will you know kick you in different directions for different identity providers in this case it doesn't sound like that's exactly what we're dealing with it maybe the same user just coming from different urls or something but they're uh so i don't have a more specific answer but that may at least give a clue about you know how you might want to uh approach this particular problem yeah the other thing you might want to do potentially ryan i'm thinking about this a little more as i'm rereading this question in my head you might just want to create two separate octa apps one with the internal url and one with the external url and you could configure them basically the same but with two different urls and as long as they're accessible you could have them set up with the same policies and same user lists and stuff like that you might be able to get around the problem by doing that it's not 100 clean solution but i think it would allow you to make things work in a way you're looking for so maybe try those things out um if you do need more help by the way just so all of you know like there's a ton of questions today i'm not sure if we'll be able to get to all of them please send us an email to developers at octa.com that's our email address where you'll get in touch with an actual developer here at octa who can help you out or escalate things if we need to to other teams if we need to figure out things for you stuff like that so feel free to hit us up there too if we aren't able to get to it today all right let's see next question okay uh steven steven asks good morning gentlemen good morning steven we are trying to come up with a touchless login and enrollment process for new employees there doesn't excuse me there does not seem to be a way to pre-populate a user's mfa factors to allow them to log in on day one in a passwordless fashion is there a way for us to pre-program a user's sms number for example and allow them to reset their password without the user having their password initially so uh the answer to this question is that it's it's sort of kind of thing so we have this feature called octa identity engine it's a new thing that we have um we announced a while ago you can actually use it in beta today but octa identity engine is sort of like our version of refactoring the octa api is almost it allows a lot of additional functionality including things like this where you have non-traditional login flows that maybe don't require a password so if you are using octa on an enterprise plan reach out to your sales rep and talk to them about octa identity engine and say like hey this is something we might want to play around with or get early access to they might be able to help you get that going um and once you have access to that a lot of these things become uh possible so hopefully that answers your question steven and one other thing i would add real quick randall is um sometimes we find our customers get a little tripped up where uh we treat factor enrollment and factor enforcement separately and we've had situations where people have uh set up factor enrollment but not actually enabled enforcement so you know users will put in their number the first time and get an sms and enroll and then they'll never have to do it again because they never set up enforcement um and so so that's something you want to look at too whether it's a octa identity engine or not you need to make sure that both enrollment and enforcement are configured properly and um by setting things as required you can force your users to have to enroll in um sms for instance uh traditionally that's done after you authenticate but like randall was saying with some of the new features you can you can have more exotic or or different kinds of workflows for how you want to manage authentication but just make sure you got both pieces of the puzzle configured properly both enrollment and enforcement absolutely all right so next question is from christopher so christopher says hey why is the search function in the octa admin panel so broken i have to memorize the first part of the name of a group in order to find a group like it's limited to a hundred items so i can't browse it why is the front page of octa what users use in instant search but that isn't available to be used anywhere else in the admin console so first of all christopher sorry you're having a bad experience with that but i have really good news for you we're uh literally days away from releasing an updated skin on our admin ui uh this is something that's been in the works for quite a while so let me just give you some history and context here to help you understand like some of the stuff we're doing and like why we're doing it this way so a lot of the admin ui today is sort of like a thin wrapper around the octa api right like it just lets you do things and one of the things we've been working on for quite a while now is that the octa product has two disparate user bases we have on one side people using octa for like it use cases like for example you know letting people log into their workspaces or log into apps using sso then we have the people on this call and i just assume all of you are like developers building custom applications using octa to manage the authentication and identities of your users right and today both of those user bases have totally different admin consoles so it admins have like one look and feel developers have a completely separate look and feel well over the last couple years our design team and ux team have been working to build a central console that's going to work for everyone and have full feature parity so what that means is that like all the stuff you can do with the api will be accessible via the ui and so instead of basically us putting a lot of time and effort into maintaining the existing ui's we've been pouring all this effort into making this new one and getting it ready and i'm really happy to say that like that's actually going to be coming out really soon so we were hoping to get that out in december before the holidays it got pushed back towards the end of this month but you can expect to see the new new ui before our annual conference octane which i think is pretty exciting if you're using our developer plans anyways so please be on the lookout for that that should hopefully help solve some of these issues and sorry you've been running into those problems hopefully that answers your question by the way all right so next question is by aileen and she has an it related question so mica and either of you want to take this one that's fine i have some employees who use octa in restrictive spaces that do not allow plug-in connectors while using browser plugins is there any alternatives we can offer them so in this customer environment these employees work in for security reasons it's really locked down but it also means that unless the sso or unless the application the user is trying to access is using saml instead of swa they can't log in without the octa plug-in are there any out-of-the-box solutions you can recommend so basically what aileen's asking is we have people using octa for it to do single sign-on into apps and some of the apps they have require the octa browser plug-in to work because they don't support saml they don't support open id connect and we need to you know pre-populate the email and password in the browser so she's wondering in these environments where we can't install the octa browser plug-in is there a way to make that work uh mica erin you want to cover this one i'm just trying to think of um what alternatives you might have uh you know swa is is kind of octa's password vault approach and if it if it doesn't support yeah standards like saml or oidc and you can't have the browser plug-in then i'm not sure how you can get the benefit of of octa's uh swa i think i have the plug-in requirement there i have one thought which is maybe a little bit unconventional but that is to set up a proxy in front of that application that does the authentication so i've actually done this several times for other for things like at home or for other for other services where the application i'm trying to protect doesn't support any standards itself or doesn't even have any concept of authentication and you can set up a proxy in front of that application where that proxy speaks open any connect can talk to octa using oidc and then only after you authenticate it'll then let the request through the back end so that's one option there where that proxy would run you know in your secure environment in front of the application that doesn't support any of the standards and then you can add it to any application that way uh we have a blog post actually that talks about that on our developer site so i think it's if you search for add authentication to any application maybe add octa to that search then i think that will turn it up i think that's a really clever solution actually too like that seems like a good workaround especially if you're in a restricted environment where there's literally no way to do this although one other thing i'll just add out there for you eileen is like we are a massive company we work with tons of huge corporations with crazy security rules and we've gone through all sorts of compliance checks it might be worth talking to your it department as well about just getting the octa browser extension included because like i said we go through tons of security checks and audits and things like that we're used to working with really large companies so if you do need help there like i'm sure octa will be able to find a way to talk to your it or security group and like make that happen too potentially um but yeah arian's workaround is fantastic uh if you can't do that lover all right so next question we're going to answer is from man deep so man deep says hey i've recently created an oidc app in octa for accessing my custom application okay awesome i'm migrating users from an oracle database to octa excuse me the oracle user in my custom application has roles and privileges for authorization purposes one role consists of nine to ten privileges or more a cuss and the custom app checks for both checks both so it's checking both the role and privileges for executing further actions how can i handle this via an octa authorization server or is there a better way to manage use so it essentially sounds like this person is going to need uh the concept of roles and privileges erin do you want to talk about the best way to accomplish this using oidc yeah we're let me try to read that question again so i can so i can find it which was the who was this from yeah it's from man deep yeah man deep so basically he's saying he has users in a custom oracle database right now and the users have two different types of like permissions they have something called privileges and they have something called roles and his application checks both privileges and roles before making authorization decisions um so you can migrate them into uh you can convert those into groups in octa would that be the best way to do that on the octa side putting users into two different groups um and then you can make a rule that adds the groups into the access token itself so that way when your api is checking the access token to validate that you can you'll get that information into the access token that you can validate at that point yeah i think the only other way to do it man deep other than what erin suggesting would be to just do it directly in the authorization server in octa so if you go to the authorization server and you go to the claims you can define your own custom scopes and claims in there and so you could just define a custom one for each of those things so like in your own custom database today you might have it called privileges and roles but in octa you could translate those all into just one type of thing called like a scope or a claim and so you could have a custom one for all of those things and then in your application when you get back a token from a user you can still check the exact same stuff it would just be under one classification set of two and one one other thing i would add there is you know sometimes it makes sense to keep certain types of data like roles and permissions potentially um out of octa or you have a requirement to do that and in that case you can take advantage of um inline token hooks and basically what octa will do is it'll reach out to your server and give you all of the information about what's currently in the access token and then you can query your own servers and add additional information to that access token it's handled in flight octa then re-signs it and then it comes to your app kind of fully form so that might be another approach if uh where where it makes sense to kind of update the the hooks on the the token on the fly uh the one caveat there is that your service must respond within three seconds where octa will just return the original token as it was um so you want to make sure that if you are going to query you know an an external api or something that's you know in your own um data center that it's responsive enough that it can keep up with the the requirements to alter that that token on the fly yep thanks for that additional context mike i think that's really helpful um all right for the next question let's go to megan so megan asked and i think this might be one for you erin um she says hey i have an application abc in octa which manages customer accounts i can create read and write roles aka scopes for application for this application and grant those scopes to my users within octa however now i need to be able to limit the roles based on individual customers within the application so like i have an octa user one two three four at dummy dot com and that user should have a read role for customer one a rewrite role for customer two and nothing for customer three so can this be configured within octa so basically like it's more of a fine grain permissioning question it sounds like yeah i have to think about that in octa uh case for a second but i would also say that i would not use scopes for this i would use a different claim for this use using groups the reason is because scopes are more about limiting what a particular application can do within the context of what a user can already do so if you have a user who has read and write roles then it lets you issue an access token that has read only access to a particular application and that's more what the scopes are for in oauth and i think if you try to use it for what you're trying to do here you're going to find that it doesn't really map well and that might be why you're you're finding this challenging you know a couple other just things i'm thinking about off the top of my head here but you know like the first thing that comes to mind when i read this question megan uh and i might be way off base here but like a call center type situation so maybe you have like support agents and you have like some support administrators in a call center and support agents and administrators would both be defined as groups within octa and they would have certain privileges just based on the group they're in okay and like erin said those are not scopes within the authorization server but let's say the person's talking to someone on the phone and that person needs support and so maybe one person wants to grant the support agent like a read access to their data and another support agent wants to grant the person read and write access to their data so they can like actually fix something for them so what's a good way to model that well a couple of different things you can do so one within our authorization servers you can define the read write you know execute scopes whatever you want and you can define dynamic like checking rules using the octa like like policies basically in the authorization server to allow certain things at certain times so that's one option another thing you could do is you could use our hooks so we have inline hooks you can use and also event hooks where you can basically like get an htgp request to your application when something's happening and your application can make a custom decision like do I want to allow this yes or no that might be a good solution because you can basically like start making an authorization request you know patch into a hook do some custom logic in your database or by talking to the user or showing them an oaf consent screen or something along those lines and like allow this person this customer to say yes I allow you to have read access or I allow you to have read access sort of like in an oaf best practices type way so those are just some additional ideas too and actually Micah I think you might have done some of this before do you have any better ideas for that stuff um it's a good question can you can you restate once more yeah so like if you if you have users in a group like a customer support agent but then you also want to have custom claims like read and write to customer data uh is there a clean way to like within octa to to manage that so maybe you have someone who wants to access a customer's data and the customer should be the one to allow them to say like yes you have read access yes you have write access yeah so you know there's a couple of different ways of that typically you know you're gonna have an application that's gonna make a request and um you're gonna get back you know a bunch of different claims in that in that token um the nice thing is that all of the frameworks um the one that I'm most familiar with is like spring boot they support functionality for saying well if you have this claim you're allowed in here but if you don't have a different claim then you're not um you know so so that's kind of out of the box functionality but that may also be another good example of where you want to use the uh the inline token hooks um and then you can you know your code can then look at who the user is and what what uh claims uh or what additional information you kind of want to jam into that um token it's kind of a very powerful and and I feel like not very well publicized yet featured to be able to alter a token in flight and then have it re-signed um that gives you a lot of power so it might not even be that you define the custom claims in octa anymore but you have a bunch of claims that end up in the token based on you know your your hook your code that does some sort of check maybe it's against your own database or it's against some other service that determines ultimately what claims you're going to end up in that token yep so hopefully that that's helpful um let us know if you have follow-up questions and we'll do our best to get back um all right next questions by Pradeep and Pradeep asked what's the best way to become like an octa developer and I think what they mean is like a certified octa developer I'm guessing um Micah is actually one of the people that deviant that uh designed our developer certification so Micah do you want to talk about that for a minute like how how can you do it how can you get certified etc yeah excellent question uh and you know I'm biased because I help create our developer certification um but from that from the main octa site I'll share my screen in a sec but there's some good information about um about getting the octa developer uh the certified developer certification um but basically one of the things I'm proud of with this particular one is that it's a practical application it's not memorization necessarily depends on how you learn but um it's not just answering multiple choice questions that's the first part but then the second part is an actual web app that leads you through a series of use cases where you have to actually make octa api requests um so I'm proud of it it's become really popular and um I think uh again I'm biased but I think it's a great way to uh to learn about uh octa in in a deep kind of way um and oh I got the spinning wheel of doom here we go so this is if you go to octa.com slash services slash certification or just just from the top level if you go to services and then education services and you scroll down a bit um here's where it talks about the uh the octa certified developer um exam and you know we have a lot we have a study guide and even a practice exam so you know we really give you a lot of support in um learning what you need to know to pass that test um and like all certifications aside from um well maybe not all but aside from you know maybe being useful for your for your job role or or being like a good resume stuff or at least in this case I think it's it's actually uh very useful in learning the octa management api and our apis in general you know if that's something that's important to you awesome hopefully that was helpful all right I think we only have time for a couple more I do my best to pick the ones I think are going to be really high value for for people um this this is a design related question so let's talk this one through for a minute Aaron Micah just give your opinions on this because it's very much an opinionated question so this person says I know this is a business and or UX decision but could you share your perspective on building branded login pages specific to a single portal or app knowing that the direct login and octa will continue to exist does this create confusion for users knowing they have octa credentials and application x credentials when in fact they are one in the same the reason for this question is because uh this person wants to embed the login experience into a new portal versus following a browser redirect to an idp so the way I'm going to interpret this and whoever asked the question like post for clarification if if we're not interpreting this correctly but I think what you're saying is you have like multiple applications on different domains potentially that are using octa for authentication and so you have these two different portals and you have the same user credentials being shared amongst both these portals and you don't know a good way to bubble that that concept up to a user so if I'm using portal a and I try to log into portal b I may not know I have an account there already and so I potentially try to create a new account and run into issues etc um Micah Aaron what do you think this user should should try to do to fix this issue I don't think you're gonna like my answer that's okay what is it I'm I'm would go more on the side of actually doing the redirect so that users do understand it is the same credential across all these applications and that it is using single sign on and that you can brand that read you can brand that page on octa right make it look like your own page don't make it look like it's octa but by doing that redirect it then reinforces the idea that this is the only place users enter their password and you don't end up with users thinking they might have to enter their password in other places that might be actually phishing attempts I think the worst offender of this is apple where you see your your prompt for your apple account your both your iCloud as well as your system account pop up in so many different places so the next time you get asked for your apple password how do you know it's actually a real prompt and not just some app on your computer that's trying to steal your password so by using the one the one login box on the redirect page you help reduce that risk and educate users that this is actually what a lot of login box looks like and anything else is probably an attack that's my opinion on it it is a design choice though so take that with take that for what you want I'm just gonna one that too I agree with yeah yeah I was going to add to that also you know same we're all in alignment which is and I understand that that's not always what our customers want to hear but we're working hard to kind of make the the whole experience of customizing that login experience better ideally especially if you know you may have a consumer facing app and your users don't know anything about octa you don't want them to ever see an octa URL so ideally you'd be redirected somewhere like login dot your domain dot com and that's something that that has not been a great experience for developers up till now we're working to make that better but I have seen scenarios where even when you're redirecting through code when you when you have a subdomain you can edit all the code that backs the sign in widget and through code you might have different backgrounds or different logos or a totally different skin on that interface depending on where they came from or you have a lot more flexibility once you're using your own subdomain to to alter that code and to make the experience that's you know going to be the the best for your users to have the best user experience so totally aligned with what Aaron is saying it really from a security perspective it is the best most secure approach for the reasons that Aaron said and others and then we're just trying to bring like the user experience or the developer experience into alignment with that security best practice if they're aligned if it's super easy for developers to set up and use and it's the best security practice that would be like the ideal world so so the person who asks this question actually responded and Chad said we did have the context correct and they agree but they're having problems selling this to the business and ux team so what I would say is hit us up if you want some help like getting on a conference call with people in your team or whatever maybe we can do something to help you out or at least we can try unfortunately though we are out of time we're actually a little over right now but thank you all so much for coming I'm really truly sorry if we did not get to your question there was a lot of questions this time so we apologize if we could do this all day we absolutely would um please take care of yourself stay safe out there stay home don't get sick and uh thank you all so much for spending some time with us today so uh take it easy everyone on behalf of octan thanks everybody great questions yep all right bye