 Welcome to the Opta workforce identity developer podcast. Today, I'm pleased to welcome back developer advocate, Alyssa Duncan, and welcome to the show SDK engineer, Jared Peralt. Hi there, Alyssa and Jared. Hello. How are you doing. Doing great. Thanks for being here. I'm obviously spoken on this podcast with SDK engineer Laura Rodriguez. So returning listeners will be a little bit acquainted with Octa's SDK work, but Jared brings us a different perspective on it. So, Jared, what does the SDK engineer role look like for you. My job is to write SDKs that conform to the OAuth spec and specifically implement Octa. Obviously, Octa is an OAuth offering and so there's, you know, certain implementation details that Octa has chosen to implement and such. And I think one perspective that I'll have that's a little bit different than Laura is that she is a backend SDK author and I work on predominantly front end SDKs focusing on JavaScript. And that you called it when we were talking about your role before was a career of reading docs that other people didn't want to read. So you're really doing that interpretation, aren't you. The docs, the specs specifically can be a little bit dry, but you know, it's just part of the gig. Yeah, absolutely. And so you're mostly on that Octa auth JS. Who is that for? Who should use Octa auth JS. Octa auth JS is basically for any JavaScript needs can reach for that SDK. It's made to execute in browsers in no JS environments. I believe there are some people that even use it in like electron apps and other things. It is quite monolithic. We do kind of plan to break it up a little bit into smaller chunks. It's kind of like the work that we're, we're looking on in the horizon, but right now, for any JS application. It's a one stop shop for bringing OAuth compatibility to your JavaScript. So this SDK work is all about making it easy for people to use OAuth and to do OAuth right. How would you describe the relationship between that spec and the SDKs that you work on the SDK is kind of trying to position itself to do all of the work for you in the areas that we can. So if you're implementing OAuth with a user, so it's a browser application, you have to, you might have to do right, write things like pixie to storage and, you know, run some, you know, cryptographic algorithms for various things. So we try and handle all that kind of stuff for you so you can store tokens and all you have to worry about is integrating the SDK into your app and then, you know, everything else is already done for you as much as we can possibly do. So if you look at the spec, you see, there's not that much about clients compared to servers and the general protocol. What's up with that. I don't know. I think that in a lot of ways that the spec is written for like zero trust clients I know we're going to talk about that a little bit but I think that the spec is kind of written to be suspicious of clients on purpose right you have to authenticate, you know, approve who you are. So I think that's, you know, kind of the kind of the reason why there isn't a lot of detail about it where a server is presumably a known entity so you have already have like a trust relationship with your with your own servers, I would hope anyway. We hear a lot about zero trust. Would you like to define how you use that term here. The way that I think about it because the way that OAuth is kind of positioned is everything is kind of from the perspective of the authorization server. I think that was something that took me a little bit of time to get my head around because I always think of everything from the perspective of a user right like I'm giving a ticket that says user needs to log into this application so I'm thinking like all right they enter username enter password, you know, what do I do with the user and password and then you know you look at the spec and it, and it doesn't say like oh give the username give the password. So the way I kind of think about it is that the authorization server has no reason to trust the client that is saying I am Jed Perot. So if you're integrating a lot from a server, you have a little bit, you trust the computer the server that is then making that request so it's a little bit more reliable to it the authorization server can trust that you are who you say you are, where a browser could be anyone anywhere anytime. There's, there's not a lot of rebuilt trust before you're identifying yourself. You're saying that zero trust means that one you always have to make sure that the person or that caller is who they say they are and they have the access to whatever resources that they're requesting. And maybe we shouldn't trust browsers. Yeah, essentially, you know, anyone, anyone can go to any website, you know and type in credentials and you know see what happens so you know yeah you have to do a little bit of due diligence and obviously you know there's there's a whole internet in between, you know the browser and the computer so you know there are many attack vectors and such that can be done there. You know these payloads are going over an open internet, you know, so you have to make sure that everything is is you know encrypted and secured and you know in transit and all that kind of stuff as well. Yeah, definitely. And so is zero trust the only way that we can do authentication or are there other tools for situations where it might only be partially applicable. So it all depends on where you want to actually interact with the authorization server. Okay, that's kind of why I'm saying I try and think about it from the perspective of the authorization authorization server. So if you want to implement OAuth directly in your your web application like on the browser. Then that would be considered a zero trust client but if you want to have your web server established like a more traditional like session between the web app and your server, you could then implement OAuth on your server. So the session basically represents some kind of UI UI ID or whatever to then access the tokens and then those tokens can be used to be sent to resource servers or whatever you're protecting. Obviously then you have to do things like manage state because sessions are you know based in state and all those kinds of things so obviously it's always more convenient to do, you know, like, I don't want to say less security but you know the less the less moving you have the simpler application isn't somewhat obviously so it is often more convenient to implement OAuth on the browser directly but it is theoretically less secure because you know the reasons we've stated when we start talking about using SDKs. It's often kind of like being trails through a park so following a trail gives you fewer choices than just like taking off into the underbrush and hiking across the stream instead of going over to the bridge and just getting straight to where you're going, but the trails are put in places where people would probably prefer to walk and often you still come to this fork in the trail and have to choose which one you're going to take. This might take you quickly where you're going another one might take longer or might not even go where you want to. So, in that metaphor, where are the big decision points when someone starts using the off JS SDK, where they'll have to basically choose their own adventure for how they want to use it. Well, they just like right at the beginning if I'm being honest like as I was saying I think if you're if you're comfortable with implementing OAuth on the client, then you know you would reach for the SDK methods that are designed to be running a browser. It is ultimately a isomorphic module which means it will run you know in in a browser or in node like on a server, but there are certain methods that are only going to execute in a specific environment. If you prefer to do something where you have a more traditional session established between the client and your server and your server implements OAuth, then you know you'll you'll reach for those no specific methods. For the most part, once you kind of choose a path. I think, you know, it's it's kind of like, you know, there's not a lot of forks on the paths themselves but I think you know it's, it's kind of like, I guess to extend your metaphor is like a ski slope, you know, you're choosing what ski slope to go down and once you're on the ski slope you're not going to suddenly you know chunk to another one. I mean, I hope you wouldn't anyway. So one of the early things that someone who's setting up the SDK may encounter is the choice of app type. So what should a developer know in order to pick the correct application type for their use case. The main app types that that we really deal with would be either spa single page app or a web app. So a web app means that the relationship to the off server is on your server it's a it's a trusted computer. And then the advantage to that is that you can use a client secret. So back to the zero trust conversation that when you have a zero trust client you don't want to provide that client a client secret as client secret is supposed to be, you know, a secret. So if you were to put that into source code that would be distributed on a browser people could easily look that up you know examine the source, the payloads that you're sending back and forth and like the JavaScript debugger. It would no longer be a secret. So if you choose, if you want to implement OAuth on the client in a browser, you would choose the spa option for your app type. The spas taken me a while to always the reference that as a single page app. We're not just sending it off for some relaxation we're actually trusting it less. The problem is it if you guess wrong about what app type you're going to use and how would you go about fixing that. It's not a big problem at all you can just very simply create another app and then you just update your off JS config with the new client ID and or client secret depending on which way you're going. So when you say create a new app you mean set up another integration in octa. Yeah, yeah we'll talk a bit about how that part of the process works in a few minutes. So what you want to make sure is that if you're running JavaScript within your own like within your own user right or your own machine so you're having a spot you have a spa you have a view app you have Angular you have react whatever. And everything is basically public right with the JavaScript application. That's what you want to make sure that you don't have any secrets in it it's called a public client versus if you have something like a, let's say a dot net NBC application or something in like Java spring, where it is all running within the context of the server, you can then store client secrets there and it could be considered confidential. So that's the way I think about it if I might if I'm writing something that is completely public, or is there a way that I can keep a secret from somebody else right to piggyback off of that you can still use like Angular view, like a traditional spa framework as a spa but still protect it from from the server. So that would be establishing a session, as I was saying and then having the server itself, then interface with the authorization server. There, there's a few inconveniences to that because one of the things you'll get from the authorization server is an ID token, which often represents the user's profile information so you can say you know like, you know, hi Jared and all that kind of stuff. But you can solve that very easily by just adding an endpoint to your server that your web app would hit upon a successful authentication. The next thing once you've decided whether your app is going to be handling secrets or whether it's going to be a public app is that you're going to start thinking about the flows that you're building. So, if this is someone's first exposure to the idea of flows in the OAuth context, how would you describe what flow even means? Yeah, I think this is something that kind of took me a little while to get my head around as well. So I, I kind of trying to think about it from the perspective of the auth server. So the off the off server is ultimately the, you know, the source of truth to, you know, whether or not it you have proven you are who you say you are. So it, it kind of describes how the flow of data to the off server and then back to the requester like flows flows through the system. So, you know, all of the components in the in the system so if it's a browser it would be a browser if it's server server. I mean if it's a if it's a browser presumably you're interfacing with your server as well at times. So it kind of just describes the transfer of information to the various, you know, actors in the in the system. I like to think about flows from, like I guess the user perspective that so maybe the opposite of the off server. I think of it as use case. So I think about how I want to authenticate into the system. Am I doing it as a user on a web browser, am I doing it as a user, you know, was it using and using a spot application am I doing it as a user from a different sort of web server at page p ad perhaps, or am I doing as a command line or you know whatever it is I'm thinking of it that way and then saying okay so now I have these associated a lot of flows that goes with that use case. So what are the most common flows that you see people using in the SDK for the client, it's going to be authorization code with pixie. That's by far the most common one. I think we do technically support authorization code without pixie, but we absolutely do not recommend that pixie is essentially a mechanism to compensate for the lack of the client secret. So that the off server has some proof that the original requester is the one that is fulfilling the request, essentially if you don't have pixie. You're sending a, you're being sent back a code and that code can be exchanged for tokens by anyone that has that code. It wouldn't be so good if, you know, someone, there's a whole internet between you and you know you and your users and your servers. Yeah, when I was checking the docs for what flows we were likely to end up talking about. I noticed that in the pure off code no pixie flow, it said just set the response type to code and pixie to false in the s config and I went, uh oh, that looks pretty deprecated. Yeah, absolutely. And so in the pixie flow which is spelled pkce and stands for proof key for code exchange. That's what we recommend for the single page apps that can't store secrets. So what actually is pixie. So what it what it is is it's a cryptographically generated string. So you have your pixie verify your code challenge and then your code, you've code verifier and at different points in the flow you'll send the challenge and then the verifier to your off server so you'll send your your challenge first and then the off server assuming you're a successfully authenticated will send back a an authorization code, and then you exchange that authorization code in your code verifier to the token endpoint which will then return tokens assuming that your code challenge and your code verifier match. Yeah, when I looked into the docs. So as far as we make a random string and then we use a hash of the random string. And because you, I think kept your random string secret, then by being able to hash it and hash it with things, you can prove that you're the same person who originally generated that So you keep someone else from jumping in partway through the conversation that you're having with the server and going, oh, well, yes, I'm totally the same person as before. They go, oh, you don't have the right hashes you don't have the same secret as before let's fail out here. Exactly. And then that would be an example of something that the SDK would do for you so anytime you would make a request with with an SDK method we generate all of the the pixie the code challenge the verifier we write it to local storage so it can be an entry later, you know, all the all the things that you would have to do to implement that for yourself that's an example of something we can do for you. Yeah, we talked about using pixie in this context with the spot but pixie should be used for anytime use authorization code blow, including for confidential clients as well because it's, it's just so awesome I like to think of it as like it is pixie powered, powered by woodland creatures sort of thing and so I'm a fan. Yeah, it's such a relatively small thing that you can do for such huge security gains that why wouldn't you enable it. Another flow that you see written about quite a lot although it is deprecated is the implicit flow. So I thought it might be worth asking, what did the implicit flow used to do back in the day. So the implicit flow can still be used today but it's not recommended for spa applications. The reason is that the way that it returns tokens to the requester is it does so through a redirect that includes the tokens in the URL as a query parameter. So your tokens are essentially just out in the open for anyone that can see the URL and that's possibly the most fundamental part of the internet protocols URLs so it's the reason it's not recommended anymore for spa applications is that I think you can still theoretically use it for more traditional web apps that are going to do like a true browser HTTP post, because then the tokens would be returned in the post body rather than as a query parameter. But that doesn't really interface with spa apps very well that's more of like a traditional web app sort of approach so you can still use implicit flow in some cases but definitely not recommended for spa. And how urgent would you say that is for somebody to switch off of implicit flow if they had ended up with it on a spy app. Yeah, I would say take care of that sooner rather later for sure. Yeah. Anybody watching your web traffic is just getting all your tokens and you're hoping that they don't decide to impersonate you. I also want to add that there's some really great YouTube videos and blog content about the implicit flow and why also to switch over to like that some of the more deeper context on that I highly recommend it it's great stuff. Is there any other flows supported in off JS that someone might see in the docs and be like, Oh, should I should I care about that is this for me. I noticed that there was an interaction code flow like would that ever beat off code. Pixie. So interaction interaction code flow is actually a extension of the OS spec that was written by octa and it's heavily based on authorization code flow. So it uses Pixie as well. But it's, it's, it's made more for a better like user experience I guess is the way I would phrase it. It you kind of interact with the authorization server in multiple interactions, rather than collecting all the data from your user like you know one form username password hit, you know, hit submit. You can, you know, first collect their identifiers return that's the server ask for your password return that's the server they may now ask for a secondary factor. You know, it may return to the user all of the factors that they have already set up so they could choose to, you know, authorize with email s mess, whatever. It all depends on how you set up your octa org but it's a much more dynamic. Well, I mean it is an API, but it's not truly a rest API so I don't, I don't usually when people say API they're talking about rest API is and it's, it's not quite that. It's all, it's all post responses. But the way you would use that if you wanted to is is the easiest way is to use the IDX client that off JS offers. The, the end result is essentially the same in an authorization code flow you get an off code authorization code back interaction code you get an interaction code back but those codes can be both exchanged to the token endpoint in the same manner. And they're both protected by pixie as well. So, for the most part when you're implementing either one of these flows they're, they're mostly the same as far as how they interface with your application. So it's under the hood, when I get this really elegant like behavior shift to using the right local verifier if I'm on my phone versus on my laptop kind of thing, the web page, and the identity server are just trading that extra little bit of information that wasn't mandatory per OAuth, but makes things run a bit smoother. So that like an extension to OAuth for humans where OAuth is a little bit more for machine to machine communication. So thinking about having that better user experience, then let's talk about authentication user experience right, because that's like a big thing people want to have highly customized pages. There's a lot of advantages of redirecting to an identity provider and then have had having them, whether it's octa whoever handle that for you. What are the options and why would you pick one or the other over the other. You would always choose, as we call it redirect model which is you redirect to octa and octa collects all the credentials from your user and then we redirect back to your application. The other thing is that then your users credentials only ever exist in an octa system where if you implement the IDX SDK yourself or some other OAuth flow, the credentials at some point will be in your system, whether it be on the browser, on your server, however you're implementing OAuth. And then you, you know, you'll have to be responsible for the fact that, you know, passwords and things could be traveling through your system. The other advantage is that, you know, at the redirect model that all the octa sign in widget and such it's always patched it's always up to date you don't have to worry about maintaining any of those types of things. Honestly, just a lot simpler to implement. We have things like the, you know, the octa sign in widget that is, you know, a preassembled UI with any authenticator you could possibly imagine we already have views and, you know, all those things for it. So, and if you were building an auth experience from scratch, you know, that would be a pretty heavy investment compared to taking one right off the shelf. Another perk to using redirect auth is that people's hardware tokens can work on the correct URL. Like we talked about in a prior podcast with Megastogi. If you do try to do embedded auth, some tokens just plain won't hand out your creds if you're not the domain that they issued those creds for. There's been a crackdown in the third party cookie for browsers. I believe the motivation is to try and prevent like, like ads from, you know, spying on all the websites and things you're visiting but unfortunately it does break some existing OAuth flows as well. What excuses do people use to keep the embedded auth when when redirect is so much more secure. You get a lot more control so you can customize the views and such a lot better. I mean obviously if you're going to if you're going to write the view yourself right you can make it look however you want to where if you're using the redirect model you're using the the octa sign in widget. There is a theming API and things that you can use to make it look, you know, closer to your brand colors or what have you but you know there's obviously going to be limitations to how, how much it can look like you know your existing web app, where if you were to do it yourself you can control it a lot better. That can sometimes be a little bit of user education going a long way as well with understanding that talking directly to the identity provider is better than giving your creds to whatever website asks for them. I would be a little bit suspicious if I'm on a website and you know it's like black and purple and then I, you know, get redirected to a page that's suddenly white and blue, you know, so I do think in a lot of cases theming is important, because it's very jarring when suddenly the page is completely different. So I would say that that that is an advantage but yeah the keeping the credentials in in only octa I think is probably a better argument for redirect model but with the brands API you really can have it both ways. You can also add the custom domain for your for that redirect to octa so it can look like a seamless experience still within your own domain name so that's also pretty helpful. And I feel like it's the days of just using a username password field is your only two authentication fields are over right so the amount of work that it takes to integrate the higher elevated security levels that we need now it's it's way beyond just a simple username password. If we're using off JS to talk to an octa tenant the docs will walk us through using the octa admin console to set up what we call an octa application. And I've noticed that that term application is really overloaded, but the way that I like to think about it is that the app that you create is kind of sort of like making a user account for the integration but it's not a user account for a person it's not where permissions management is done in a way that makes sense for a machine talking to a machine instead. You have any tips for making the right choices when you set that up. Yes, I think we kind of touched about it a little bit earlier. If you do choose to implement OAuth on the browser directly then you'll want to choose spot application as your app type. But if you want to implement OAuth on your server then you would choose web app. And it'd be slightly more secure because you'll get the advantage of using a client secret. But in some cases can be a little bit less convenient than having the tokens directly on the client. And then yeah you'll have to select which grant type you want and that will correspond to what off flow that you're trying to implement. Maybe I'm a little biased, but I don't think it's all that hard to set up. Like my first week at Octa I had an app up and running in like a few hours. So it's like I was going back to the ski slope example once you kind of get started you know you're going to reach the bottom of the mountain one way or the other. I've definitely found that whenever anything goes wrong setting up an app it's because I skipped the step following the directions. When you do each step in order it works great, but you do have to make sure that you match between what your code is configuring to try to ask Octa for and what Octa is told. This is what I should give to this client because any mismatch there could represent someone attacking you trying to misuse your creds. And then we've also got a lot of framework specific SDKs for various JavaScript frameworks. Do you have thoughts on when a dev should choose the framework specific SDK or just use pure off JS? The way I would describe the framework SDKs is they're a little bit of a opinionated implementation of I guess off JS. So they're set up to heavily favor redirect model and I think all the samples and in such even only really illustrate using the redirect model. If you want a more customizable experience you may just want to use off JS yourself. Ultimately these framework SDKs wrap off JS so you'll still have your off JS instance available to you through the framework SDK that you're using. So you can still reach for off JS methods when when you need to. Yeah, if you're just trying to get something built very quickly using the framework SDK with a redirect model is the fastest and easiest way to do it. So you were talking a lot about spas here in this example but what about other sorts of JavaScript based applications like maybe just node to save an express API or if you have. So you're writing a web app in express, you know, using a templating ancient like what are other options there as well. Yeah, so that really goes back to where you actually want to implement a lot. So you can have a express server serve, you know, server react app, but if you are protecting a resource server that's independent of that express app maybe you want the clients on the server so the client can reach directly to the express app. So in that case to have your express app kind of exist as like a middleman proxy so that you know your back end resources are never accessed directly from a browser they go through your express app is like an intermediary. So in that case it might make more sense to have your tokens, your OAuth integration on the on the server in the express app itself. In that case you might just establish a very traditional session between the express app and your react app and your react app at that point wouldn't need any octa SDK, it would just be the session as as everyone knows it today. So you could use off JS on your within the express app however to do interface with with octa to actually get your tokens on the server side. Where would one use like the JWT verifier SDK I think I saw that as an option, and the OIDC middleware. OIDC middleware is similar to like octa react octa view where it is a opinionated implementation off the top of my head I'm not sure what flow it uses but it uses past uses an open ID client under the hood and passport integration. So you can just add it as middleware directly onto your express app and the idea is that you get all that all that stuff for free. And the the jot verifier would be used if you want to verify a token so if you have a token on the client and you're sending it back to your server and you want to verify that the token hasn't been tampered with, etc. JWT is like ID tokens are ultimately signed. If for whatever reason you need to verify that your your token hasn't been tampered or you want to verify further verification of the token you would reach for the job verifier. But the job verifiers is only ever made to run in a node context that would be a server only application. Thank you so much for joining us today and educating us all on the front end of the SDK world. Is there anything else that you would like developers to know as they're using off JS. One thing I do think that off JS does a poor job of is is there's not an easy linkage between the off flow that you're reaching for and the methods that you would be utilizing in the SDK. That's that's something that we're we're trying to fix that I think I mentioned at the, at the top that we're thinking about breaking apart off JS to make it a little bit more digestible. I think it can be a little bit overwhelming of an of a library right now because it's made, you know, to to run everywhere and do everything. So there's so many methods in it and you know they're all named after authentication so they all sound the same so it's it can be difficult to determine which method you want to use and when. And I think part of it most of that is is a documentation issue I think we could definitely revamp though the read means a lot and link them more carefully to the OAuth spec. The OAuth spec just kind of keeps moving we need we need to keep our docs up to up to date specifically the the read me but I think that's that's probably a big, a big thing that we need to we need to address on our end. So I don't know patients maybe but. Yeah, I think that's something to keep in mind if if you're trying to link your OAuth flow to methods in the SDK and you're you're struggling to link the two I don't think you're alone in that. I myself and I read the docs sometimes go like, huh, and I have to go look into the code to figure things out so you're not alone. If you have any problems though, make sure you let us know you can add comments you can file a GitHub issue you can add a comment to the developer forums and we'd love to hear about it and help make it easier a better experience for you. And thank you both for joining me today and thank you to our listeners for sticking with us through this and learning with us. So go ahead and let us know in the comments what you'd like to hear about in future podcasts. And to go into more depth on the SDKs are there other options tools that you'd like us to track down an expert on we would love to hear about what you would like to hear about.