 and thank you all for joining. Good morning, good afternoon, good evening wherever you are joining from. I'm Aaron Parecki and we have Micah Silverman here as well. So we're going to kick things off today by telling you a little bit about what to expect throughout this marathon live stream, six hours, and we've got a bunch of stuff in store for you. There is a link down in the description below to the full schedule in case you want to jump in and out throughout the day. And the rough schedule of what we're doing is we've got the, we're going to kick things off with the lab session. So that's Chris Berry's lab going through building a building an OAuth application. And then we'll do some Q&A mixing with some other live demos and other guests coming in and out. Broadcast the API lab session after that and then do some more live Q&A and additional demos. Micah, can you tell us a little bit about what to expect from the lab session? Yeah, so the labs are loosely related to each other. They follow kind of a story thread throughout, but basically you have this application, a spot with an API backend. And in the first session, we're going to secure that spa app using octa and behind the scenes using open ID connect, which is a standard that octa supports. And then in the second lab, that spa app interacts with an API to get data and render it on the single page app. And so then in the second session, we're going to secure that API using OAuth, which octa, which is a standard, and octa also supports that. So you start out with a fully functioning application with a front end and a back end not secured in any way. And you end up with a spy application with an API backend that's secured both on the front end and the back end using octa, using octa support for these standards. Yeah, excellent. That is, that sounds great. And we'll have a similar story for the API session later in today. So throughout the, throughout the demo or the lab session today, you will hear them reference the, the interactive labs like hands on aspect. And we obviously aren't going to be able to do the one on one that you get in the actual live session, the zoom session. But instead, we do have links to all the resources that they're using in that session. And those are again linked below in the description and also on the event page. And we'll drop a link in the chat as well. We will also be here in the chat able to answer your questions as, as we're going through this, but you don't, you're not going to obviously be able to like talk to us and ask questions in person like you would be if you were in the in person, in person, in zoom session, but feel free to follow along with those. Anyway, and we will be here, you know, able to help you out live. So with that, and I think, I think we are ready to kick things off. So anything else we can think to add to that before we jump into the labs, Micah? I know sounds good. Let's do it. All right. So in that case, we will roll the roll the title and start the labs. So see you in the chat. But welcome to the post octane, secure your apps with octa. Like I said, we'll get going soon. This is Chris Berry again. I think we'll wait just couple more minutes and then we'll get going. We have just a few people right now. And but like I said, we'll get going in just a minute. All right. My name is Chris Berry, and I'm going to be your instructor for the next gosh, I guess two and a half hours. In this session, what we're going to do is we're going to talk about securing using federated authentication, a application using octa. I'm a principal technical instructor here at octa. And I think I have all the certs. So let's jump in. I doubt I'll make any forward looking statements. But if I do, please take them with a grain of salt, because our roadmaps are subject to change. If you do have a question during this presentation, one of the things that we're doing is we have a large team of octa experts who are on the line. And so if you do have a question, please send the question to everyone. And then our experts can answer that question. I, unfortunately, am going to be not answering the questions just because I'm going to be focusing on giving the presentation and then doing the demo of the labs. But like I said, in the zoom environment, just launch that chat window. And if you do have a question at any time, type it in there. And like I said, our experts are on the line to assist you. All right. So we have a scenario here. And the scenario is that we have an application that has a front end and a back end. And so our end user needs to be able to securely access this application. And the application needs to be able to securely request APIs on that pack in. And so what we're going to be doing today, we're doing two sessions. The first one is to secure the front end up. And the second one is to secure those back end APIs. We're going to use federated authentication also referred to a single sign on to secure that application. And then in the other session, I assume a bunch of you have registered for that one, we're going to use Octa's API access management, which utilizes the OAuth specification in order to securely access those APIs on the back end. Our goal here is to prevent that hacker from being able to access that app and that API. One of the things that we do at Octa is we basically have an architecture, which you could say is zero trust. And the idea to me behind zero trust is even on your private network, your corporate network, to implement internet grade security standards so that if someone were able to obtain access to that network, because you're using standards like OpenID Connect and OAuth, you're a lot less vulnerable to attacks by those hacked or hackers who gain that access. So like I said, our focus is going to be on that front end for this first session, the other session we're doing, secure APIs will be on that back end. All right, I'd like to do a little bit of defining. So at Octa, we use a few different terms. Primary authentication and federated authentication. When we're talking about primary authentication, typically what we're referring to is the basic username and password authentication. And these days that's evolving, we're moving towards a password list. Typically, this is combined with a second factor, and then you have multi-factor authentication. But the idea is that a individual is proving their identity. With federated authentication, what we're doing here is we're creating a trust relationship between a resource that your end user is accessing, a trust relationship between that and Octa, which is going to be that identity provider. And so what this ultimately gives that end user the ability to do is to seamlessly access that application without having to do primary authentication again. So when we combine these two processes, the primary authentication and the federated authentication, our end users are able to do single sign-on to log in once, and then they're able to access these different resources using these trust relationships and not have to be impeded by memorizing and entering in, even if we're automating entering those credentials. And so we refer to that as federated single sign-on. Now, what we're going to do is we're going to focus today on utilizing OpenID Connect in order to do federated authentication. What OpenID Connect basically defines is a mechanism to provide proof of completed primary authentication and or multi-factor authentication. The way that it does that is it shares something called ID tokens, and ID tokens are based on JSON web tokens or JOTS. So when we take a look at the options for doing federated authentication, there's SAML and OpenID Connect, and I just want to point out that you do have this choice, but the reason that we recommend OpenID Connect is that it has a number of advantages because it is a more current standard. So when you think about SAML 2.0 that was finalized all the way back in 2004, back when XML was the preferred format for documents in the enterprise. And then also, if you think about the iPhone arriving in 2007, something like SAML predates our modern smart mobile devices, and so it really doesn't take into account the types of applications beyond the basic form-based web applications that existed at that time. So both of these allow you to do federated authentication, but OpenID Connect is more lightweight. It works with modern application architectures. It's easier from a development standpoint, and it also shares a lot of commonalities because it is based on OAuth. You can also use OAuth in order to do that secure API access, so it has this associated specification that makes it even more useful. Now, even though OpenID Connect has a number of different advantages, I just want to say that there's nothing broken about SAML. So it is by far and away in the enterprise the most dominant standard for doing federated authentication, and so there's nothing wrong with it per se. Just saying if, to me, I think of SAML as being the car engine that runs on gas in OpenID Connect is the electric engine. These days, if you're going to build a car, you probably want to build one that's an electric car rather than one that uses a gas engine, and so nothing wrong with SAML. It's just OpenID Connect is our recommended way to go. So when you think about OpenID Connect use cases, where are the places that you should be applying it? If you have native mobile applications, if you have new homegrown applications, if you have situations where you have your end users entering in multiple credentials in order to access different sites and apps that are under your control, OpenID Connect is a great fit for those scenarios. It's a maybe for something like header-based authentication applications that you have. So Octa does have a product, the Octa Access Gateway, which acts as a bridge to those much older types of applications. And so you can go about it solving the problem by either re-engineering the application to use something modern like OpenID Connect, or you could use a tool like Octa Access Gateway and use that bridge to access those applications. Where it's not ideal is when you can't modify the source code, so this assumes control. And if you do have those existing SAML applications, like I said before, there's nothing broken about SAML, per se. It's probably not worth the effort to re-engineer a existing SAML application to do OpenID Connect instead. Now, when we think about the actors in OpenID Connect, it's really a relationship between three different parties. So we have your end users, your applications, your sites, and then Octa. Now in OpenID Connect, the end user is simply called the end user. They're the ones who want to access those resources without that friction of being able to log in again and the security implications of having multiple credentials to remember. We refer to your application or site as the relying party. This is the app that wants to provide that access without requiring re-authentication again or primary authentication again. And then Octa is going to be your authorization server. Octa does many things beyond what we're just displaying here, but within what we're doing, it's going to do that primary authentication of the user and then perform federated authentication by issuing tokens that are then used by the relying party to automate that access for those end users. So if we were to have this kind of diagram showing the relationship between these two, here's our end user going out to the authorization server and then going to the different relying parties. Within Octa, we can do this either by starting at the relying party or the user logging into Octa first, and then doing what we would refer to as IDP-initiated single sign-on, where the user would then click on a tile on their end user dashboard in order to access those applications. So we support a number of different architectures for what you might want to do, whether it's doing authentication for a single app, multiple applications, or app-initiated or IDP-initiated. Let's briefly talk about ID tokens, which are a implementation of a JSON WebToken. A JSON WebToken has three parts. It has a header, a payload, and a signature. And so the purpose of the header is to identify the standard algorithm that's used to generate the digital signature. The payload is where we're going to have the identity data that we're passing from Octa to the endpoint application. So this is the relevant identity information that that application then uses to provide access. And then the signature is the digital signature. Now the purpose of the digital signature is so that the relying party can trust the data which is in that payload. There's a couple of key things that that digital signature provides for us. One is that we know the origin of the token. So the way that that works is that only your Octaorg has its private key, which is used to sign this token. And then the second thing is non-tampering. So when we generate an ID token, we want to make sure because the payload is actually not encrypted, it's, you know, if you're doing it over HPS, it's definitely encrypted that way. But theoretically, someone could get into that payload and attempt to make a change to it. Because the digital signature is generated where the payload and the header are used as the seed data, what we're able to do is to guarantee that the verification of the digital signature will fail if the payload has been tampered with. So when you take a look at an ID token, what you're going to end up seeing, this is just kind of a shrunk down version of one basically so it can fit on the slide, but the data in an ID token is going to be base 64 encoded. And so when you decode it, what you're going to see are these two JSON objects with a bunch of key value pairs. We refer to these key value pairs as claims. So an ID token contains claims, which are the identity information that we're conveying. So taking a look here, let's break this down a little bit in terms of what's relevant to the relying party or the application. Within the payload, the first claim that we see here is the sub. Sub is short for the subject, and this is really the who in terms of who is accessing this application. When we're talking about a user-based application, this is going to be that user's octa user ID. It also might be an application ID. So if you're using something like OpenIDConnect or OAuth in order to access, I should say it's actually OAuth specifically, not really OpenIDConnect. But in an OpenIDConnect or in an OAuth token, which is actually technically an access token, it could be something else. Now that I think about it, OpenIDConnect is inherently user-oriented, therefore it will always be a octa user ID. There's also identity information. So for instance, here we have the name of the user. This kind of information can be used, let's say, if you're doing just-in-time provisioning within the application, you can use this identity information to provision that account if it's the first time that they're accessing it. The issuer, ISS, this is who generated the token. So remember that octa is the issuer of these tokens, your octa org. And so what you're going to see is the URI for your org. And so in this case, here we have HPS colon slash slash octaice.octa.com. Just imagine this being your company.octa.com. The AUD is the audience. This is the intended recipient of the ID token. This is the application ID here. And so this is a unique ID when you declare the application in octa as an OpenIDConnect application. Octa is going to generate this value. And like I said, this is the ID for the relying party. It's the intended recipient of the token. There's a couple of timestamps here, the issued at timestamp and the expiration timestamp. Probably the more important one is the expiration timestamp. And your application, your relying party can check to see is this an active token or one that has expired. There's also a few other things within these JSON web tokens. JTI is an identifier for the token. Think about it as an ID for the ID token. There's also an IDP, which is a reference to the identifier for your IDP. You can do things like use octa and OpenIDConnect with social authentication in which case you define an external IDP. The preferred username is very important. So notice here we have a preferred username joe at octa.com. If you think about the applications in your environment, I'll use myself as an example. A lot of the applications I access, my username is chris.berry at octa.com. In some applications, my username is just chris.berry and then in others, it's cberry, C-B-A-R-R-Y. So for each of these different applications, having their different application name formats, the purpose of the preferred username is to send that app-specific username. So whatever that identity is within that that endpoint, so that we're able to translate it to the format that we need. You can do that transformation either in an automated fashion using octa's expression language or if need be, you can do a manual override. So for instance, maybe there's two chris berries in your organization. I might be C-B-A-R-Y one or C-B-A-R-Y two and you can do those manual overrides where the expression language, the automated generated value needs to be modified. So when we think about an ID token, on the left-hand side, here's an identification card that is from the state of California. And on the right-hand side, we have our ID token and these have similar purposes and similar goals in terms of what they do. So if we take a look at this ID card, it was issued by the state of California. And so ID tokens are issued by your unique org. Within the identification card, there is an ID for this person. So in this case, I1234561, this would map to the subject. It's really an identifier that answers the who question. It also has an expiration for that matter. It has an issued time, which unfortunately, in the case of the ID, is that ISS in the bottom right-hand corner. It also has identity information. So when we take a look here, in this case, here we have a Seiji sample and an email address. In the case of an identification card, we have physical addresses. In the internet, we have electronic mail addresses. And then finally, built into an identification card are a number of different security features. And the purpose of those security features is that the identification card can't be falsified. So there are things within here which prevent it from being copied, you know, things that make it hard to modify it. If you were to, I don't know, take a razor and try and pull out a part of it. All these different security features with holograms and anti-copier types of technologies and chips, all of these are in there in order to prevent somebody falsifying an identification card. And so it's all about trust. It's all about the integrity of the data that's being presented to you. All right, so I had a very quick quiz that I'd like to take you through. So we talked about the OpenID Connect actors. And then we also talked about the different claims that exist within the ID token, which is a JSON web token. So taking a look at this list, we'll start with the first one, which is the authorization server. So over on the right hand side, A, B, or C, which of these claims would represent the authorization server? We'll give you a few moments to think about this. So the authorization server is represented by ISS. The authorization server is the issuer of the token. Let's move on to the relying party number two. So A or B, what's represented in the ID token, which claim in the ID token. So the A, the odd or the sub. So the relying party is the audience for the token. It is the intended recipient of the token. So its correct answer here is A, which means that the end user is represented by the sub. So that is the who the subject of the ID token. Now, within OpenID Connect, there is this concept of scopes. And what scopes define within OpenID Connect is they determine what pieces of identity data are going to be returned by the authorization server. In other words, what types of identity data are going to be placed into that ID token? There is one that is always required, which is OpenID. This is the base ID, base identifier information, and so this is going to include that sub. The profile is going to include name attributes, the app specific username. The email is the email address, address is physical address, phone is the value of the phone number field with an octa, not the mobile one. And then there's a special one, which is offline access, which will also request a refresh token. Just so you know, we're not going to get into working with refresh tokens too much here. But the idea behind a refresh token is that it allows a long-lived session in the sense that a refresh token can be used to obtain a fresh ID token. And so it doesn't require user intervention in order to do that. So when we take a look at the endpoints that are being hosted by octa, there's a number of endpoints which are associated with every octa.org. And you can find them by going to your base URL and then going to slash ooff2 slash v1. Under here, you'll find these different endpoints, authorized token, user info, keys, introspect, revoke. There's actually a few others. The authorized endpoint is where you're going to send the user via a redirect in order to initiate the process of requesting the token. A number of things might happen. So if the user is not yet authenticated, they would need to authenticate. We also have an implementation for providing consent. So when you think about sharing your data with a third-party site, one of the things you can do is require that the user consent to sharing that data. But ultimately, what's going to happen is you're going to go through a flow or grant and end up on the token endpoint. Now, the token endpoint is considered the back channel. It's where the relying party communicates to octa, the authorization server, to ultimately request the token. It says server-based applications, but these days it can be a client-based application using something called the authorization code flow with pixie, proof key for code exchange. But that token endpoint is where the relying party actually obtains the token. User info is a place where you can obtain identity information about a current user. So think about your providing access, but there's additional data on that user object in octa. So you want to provide that access to those attributes. You can go to user info to obtain additional attribute data off of the user object. Keys. This is where you obtain the public keys used to validate the integrity of the ID token. So the way that this works is that essentially octa has the private keys that it never shares, but it makes available the public keys on this keys endpoint so that any relying party can go out and validate the authenticity of that data contained within the token. You can do this either by doing local validation by using a standard JSON web token library or you can use an endpoint called introspect. Think of this as essentially a web service that octa provides in order to check the validity of a token and obtain metadata about it. And then finally, there's revoke. Revoke will invalidate a token, typically more used in oauth situations, but think about some other system saying, okay, what we're going to do is we're going to revoke the token and what this will do is it will essentially expire it or make it invalid going forward. Now, when you define an application in octa and you specify that application is an open ID connect application, what octa is going to do is octa is going to generate client ID for you. And so we have three different examples of open ID connect applications with three different client IDs. Now, the first one represents a client ID for let's say a custom application or a homegrown application that our organization has created. So what you do is you go into octa's administrative console, you can also do this via API. You would define a new application of type open ID connect and then octa is going to generate that client ID. Now, also within the octa integration network are a number of applications that use open ID connect to do federated authentication. So here we have dragon boat. So dragon boat is a fairly new software as a service company. And so they've chosen to use open ID connect as their federated authentication standard. So in this case, once again, when you add that application from the octa integration network, octa will once again generate that unique client ID. And then we have an example of social authentication. So in this case, if we wanted to offer up the ability rather than doing primary authentication with the username and password, what we could do is we could use social authentication, which is another form of federated authentication where a person would go to an external website and then authenticate there using a password and then ultimately that site would communicate either using an open ID connect ID token or an OAuth access token. We'll get in that in our next session in order to provide authenticated access to octa. So these client IDs are unique identifiers for each open ID connect app. I talked about this grants and flows. So these are the procedures, the different steps that are used to obtain the tokens. So first off, the relying party requests an ID token from the authorization server. In this case, it would go to that authorized endpoint. If the user is not currently logged in, then octa, the authorization server is going to authenticate that end user. The authorization server is then going to return that ID token to the relying party. Typically, the relying party is going to request it through the token endpoint. And now that relying party has that user's identity information. When you set up a open ID connect application in octa, there's a few fields that you're going to need to define. And I just want to go through a couple of URLs. The first one is the initiate login URL. What this is is at your app or site, your relying party, this is a place where a user would be redirected to this location. This would initiate the process in order to request those tokens and to do federated authentication from octa. So think of this as most of the times that a user would initiate the process of doing federated authentication, they're simply going to go to a protected area of the application. And then that application is going to detect that they don't have an active session. And so what they're going to do is they're going to redirect the user over to the redirect URL, which is our second one. In this case, the initiate login URL, think of it as a sort of a dumb destination where if this is requested, it automatically initiates that process. The redirect URL is where, let me actually kind of finish this out. So when the user does not have a session with the application or site, they get redirected over to the authorized endpoint and the application identifies itself with the client ID. What's going to happen is octa is going to check to see is the user logged into, they have a valid session already. Assuming that in this case that they do, what we would do is we would send them to the redirect URL. The redirect URL is a URL at the relying party. And it's going to do one of two things. It's going to receive either a temporary authorization code, which is much more common these days for the purpose of doing the authentication code flow with Pixi, which is really the gold standard, or the authentication code flow for server-based applications. Or if we're using something like the implicit flow, it will receive the ID token directly. So rather than complicate that, talked about the temporary authorization codes, don't worry about that too much. For what we're trying to accomplish here, just think about that redirect URL as being the place that is going to ultimately be in the application, which is going to either receive or request ultimately at the token endpoint the ID token. All right, another quiz. So I hope you like quizzes. We have a few of them in here just to keep it a little interactive. So when we think about the open ID connect term on the left-hand side, we have claims. What definition on the right-hand side best defines claims? So there's a lot of words, so I'll give you a bunch of time to think about this. So our definition that we're going to go with for claims is B. So claims are the pieces of identity data contained within the payload. So what about scopes? So A, C, or D, what best defines scopes? So scopes define what identity data, in other words, which attributes from the user object in Octa are going to be returned from the authorization server. So for tokens, A or C, so the tokens are the format, in our case JSON web tokens, for sharing data between these systems. Because JSON web tokens, we can verify the origin of the token and that someone is not tampered with that payload, we can then trust it, which means that number four is the flow, is the procedure by which the relying party obtains proof that the user has completed primary authentication already. All right, just so you know, Octa supports a number of different flows. And so these days, there's, I think, five that we support, basically for different application architectures and relationships for applications within your environment. All right, so let me just walk you through a flow where it's a little bit simplified just because we're putting this on a single slide. But what we're showing is an app initiated single sign on flow. And in this case, the user does not have a session with Octa. In other words, they have not yet completed primary authentication or multi-factor authentication with Octa. So in this case, the user would navigate to relying party A. The user does not have an active session with relying party A. So in this case, this is workforce identity. And what that means is that rather than creating a, you know, a purely custom user interface that might be powered by Octa's APIs, instead, we're going to let Octa do the authentication of the end user. And so what's going to happen is we're simply going to redirect the user over to Octa in order to request the ID token. Octa does not have a session for this user yet. So their user is prompted to do primary authentication and possibly multi-factor authentication. After the user successfully completes MFA or primary authentication, a session at Octa, your Octa org, is going to be established. We do that by creating a cookie. And what's going to happen is an ID token for relying party A is returned. And so now we can use the identity information within there to create a session. Now, like I said before, it's a little bit trickier than this. We're kind of overly simplifying things in the case of these days. In step six, you could actually break step six down into two pieces where it receives a temporary code that we then use for a call to token to obtain the token. But for the most part, six, if you just think of it as a big tent in terms of a process, it's a little bit more complex. But don't worry about it for now. Now, the second sort of scenario here is that, all right, the user has successfully logged in to relying party A using federated authentication. They've successfully logged into Octa using multi-factor authentication. Now let's talk about relying party B. So the user navigates to relying party B. The user does not have an active session with this second application. So the user is going to be redirected over to Octa to request an ID token for the B application. Now, in this case, the user already has a session for this user. So Octa has this session. And so what it's going to do is it's simply going to return the ID token to relying party B. And now we are off and running, and the user has seamless access to that application. All right. So what we're going to do is we're going to do a basically do a demo of the hands-on labs. So what we're going to give you the opportunity to do once I'm done with the demo is to actually do this yourself, which is to set up an application within a essentially a sandbox environment that we've created. And then what we're going to do is we're going to modify that application. It's a pretty simple JavaScript application. We're going to do some configuration in an Octa org, which contains some credentials, which we're going to share with you soon. And then we're going to update that application to request the ID token from Octa and parse the ID token. In our case, we're going to be using the Octa authentication SDK for JavaScript. So this is one of our many SDKs that we make available via our GitHub repository at github.com slash octa. In the hands-on lab portion of this, we're going to give you a PDF. You can see we have a pretty short URL there that octaeducationservices.com, so octaes.com, and then slash secure app lab guide. Now, here's what I recommend. I think a lot of you are going to be itching to do this on your own. I recommend that you simply watch me do a demo. You can sit back and think about the different concepts and ask questions via chat. And then what we'll do is after I'm done, we're going to devote the rest of the time so that you can work on it on your own. And we're going to go to breakout rooms where we're going to have a bunch of our lab assistants be able to assist you. All right. So what I'm going to do is I'm going to go out to a hosted virtual machine. And so the location of this is added a website. Also, this is, you know, just, you know, this, when I do this demo, you know, in the lab guide, you have this, you're going to have the same instructions. Please don't start now. Please just watch. And then we'll, our lab assistants will assist you with getting this all to work. But what we're going to do is we're going to take a unique access code that is assigned to you. I'm going to paste this number in and then click on login. Please do not use my number. And what's going to happen is going to prompt me for my name. One second here. Do not enable password protection. But I do need to consent to the policies. I'm going to click on OK. And so essentially what this is, at octa.instructorled.training, this is a hosted, a bunch of hosted virtual machines. And so we've pre-configured these to have the necessary, you know, software in order to get this to work. So I'm going to go from the lab tab and then click on this connect to the lab. And what's going to happen is this is going to take me to a virtual desktop. It's taking a little bit of time. It's just firing up that, firing up that server. Here we go. A little bit slower than usual. Hopefully not too much longer. And Murphy's Law. Once I get a ton of people online, it's suddenly the slowest I've ever seen it. So hopefully, there we go. All right. When you get to this point, it's going to prompt you. It's basically a Windows server to log in as the Octyce administrator or the other user. In this case, I'm just going to select, you could actually, I'll follow the instructions, select other user. Sorry about this. It's a very slow lag right now. So once we do go in here, I just want to point out that the password for every system that you access is going to be, it's in the lab guided, but it's trained me for three, two, one. Fortunately, not sure what's going on. Usually this is super crisp. All right. Yeah. Unfortunately, let's see here. It's just not responsive. Let me try this again. I'm just going to restart the browser. Let me try this again. Go back here, enter in my access code. Hopefully I get a better response this time. Back to the lab. All right. All the ADD. All right. So administrator. Password is train me for three, two, one. It is in the lab guide. And so I'm just going to log in now. Hopefully whatever that was is beyond us. Okay. So the next thing that I'm going to do is you're going to do this also is I'm going to download some files. What we're going to have you do is open up a command prompt. And we're going to have you go to the root directory, make a directory. And the name of this directory is class files like so. And then what we're going to do is we're going to grab the files that we need. And so the files that we need, oh, it's not in the documentation. Let's see here one second. Can someone send me the, in the Slack, can you send me the link for the lab files, please? I know it's an Octa ES1. Thank you very much. All right. Got it. All right. Sorry about that. Let me download the files. So octa es.com slash dev lab code. Should have just committed that one to memory. All right. So I'm going to download these files. What I'm going to do is unzip them and place them in that directory. I want to go over here, this PC, C drive, class files. There we go. Okay. So now that I've done that, I have the directories I need that I can now go in and use to update my application. All right. So moving along here. All right. Next thing I'm going to do is to log into my unique assigned org. So in my case, I've been assigned this org, which is of this format octane, and then a unique six-digit number. So octane, and then mine is 217-000.octapreview.com. And so we're going to have you log into these environments octa training and then train me for three, two, one, like so. Enter in a forgot password question. Doesn't really matter what you enter in there. And then select a security image. And now we've set up this default administrator account. All right. So let's get on to more of the kind of the key stuff that we're doing in here. All right. So what I'm going to do is back in my command prompt window, I'm going to go into that folder that I downloaded the lab files to. So go to dev day, and then go, there's basically going to be three directories in here. The one that you want to, oh, there's a dev day inside the dev day. Let's do this. What about this? Let's do a three folders right here. Let me just move these real quick. Place them in the parent folder. And there we go. All right. So in here, there's going to be three folders. And so what we're going to be working with entirely is just the one called promo spa. We have another session on APIs. We'll be using the other two. So for right now, we're going to go to promos and then spa, like so. All right. I'm going to do an MPM install. So I'm going to let this run in the background because it takes a few minutes to do its thing. In the meantime, I'm going to go in here and we have Adam installed on these. And so let me just launch this. You're going to see a bunch of warnings. We need to update this. There's a lot of out-of-date packages that we're using. But we're using the latest and greatest when it comes to the Octa SDKs. So within here, what I'm going to do is I'm going to open up a project folder. And so I'm going to navigate to that class files folder that I created. And what I'm going to do is simply select the dev day. And so the one that I'm interested in, key thing here is the promo spa. I know there's a promo spa API client. We're going to use that for the next class. Please do not use that. All right. So within the promo spa, just want to point this out. Under the source folder, there's two, a few key things. This is a view.js application. So view.js is a JavaScript framework. So similar to React and Angular. But it's pretty easy to work with. And that's why we chose it. Within here, there's a bunch of these HTML pages which have the extension of .view. These are the pages which dynamically render content based on the JavaScript logic embedded within them. Now, the thing where or the place where we're going to be making changes to the code is here under the off folder and the router. Now, starting with the router, the purpose of the router is that when a request comes into our single page app, what the router does is it does one of two things. It either is going to return one of those components, one of those HTML pages, or it's going to call a function. What we've done is we're going to import all of these different functions from the off folder. And so let me now jump to the index.js. This is where we have our functions that are going to do things like request and parse the tokens that we get back. Okay. So I'm going to return back to my command prompt now that I've opened those up. And what I'm going to do is do an MPM start. I'm going to start up the web server. And so now we should have an application that we can play around with and we'll update that application to do federated authentication. So as of right now, the idea behind this is if you navigate to my profile, it basically displays a profile page showing a bunch of identity information. And right now we're not, we don't have anything. So this is going to be blank. So let's now fix this. So in order to fix this, the first thing that we're going to do is we're going to need to declare the open ID connect application in octa. So I'm going to navigate down here to applications and then applications. I'm going to define that I want to add a new application. And then what I'm going to do is rather than selecting an application in the octa integration network, instead what I'm going to do is I'm going to click here on create new application. There's a number of different platforms. So in the case of a traditional form based web application, you could use secure web authentication, which is our password manager, SAML 2.0 or open ID connect. In our case, though, we have a single page application, a pure, you know, web server based no app server. And so we're going to select open ID connect. And what's going to happen is it's going to prompt us to name the application. So I'm going to call this the promos app. The idea behind the promos app is that we're basically displaying coupons for our ice cream customers. I'm going to add a redirect URI. Now this is very important because this is how this is basically an allowed list of URLs that octa can either return the token directly back to or to return a temporary authorization code to. So this is essentially, like I said, that allow list of places where we'll communicate to. So this is definitely a part of the security features within open ID connect. We're just going to enter in local host on port 8080 and then token callback. I'm going to click on save. Now, what's going to happen is that at this point, octa is going to generate client ID. And so within this area here called client credentials, nice handy little copy to clipboard button that I can use. And so what I'm going to do, just go into notepad and say this is the promos red client or not red. We usually have multiple versions promos app and ID. And I'm just going to paste that in so I can reference it later. Now, another aspect for those of you who've worked with octa and understand the way that we provide authorized access, a user is not able to access an application until we've assigned that application to that user. So we're going to be pretty lazy here. We could have made you create a mock user and a mock group. We're simply going to go in here and say, let's assign this application to everyone, basically the everyone group within octa, which is a default group. And now everyone within our org has access to this application. Typically, you're assigning it to a subset of people. But that's just our sort of our shortcut we're going to do here. Now, another thing that we're going to do is we're going to go under security and then API. And the reason is, is that are we need to set up what's called a trusted origin. And so the purpose of a trusted origin, it really has two use cases. If you're not working with an open ID connect application, you could use a trusted origin to once again have an allow list of places that octa can redirect users to. In our case, we're going to create one for the purpose of course, cross origin resource sharing. So I'm going to go in here and click on add origin. I'm going to call this once again, the promos app. And so I'm just going to go in here, local host. And then once again, we're running on port 8080. You don't need to do any URLs, but we do need to select this. Now, what this is going to do is this is going to this is basically a browser and for security feature. And the way that this works is that it is going to enable our application to be able to do a XML over HP request to our octa org. And the reason that we need to do this and the reason it's called cross origin is that by default, a browser will allow a Ajax or XHR call back to the origin from which that page was issued. But if we're going to a different URL or a different domain, in this case, the page being hosted on local host 8080 needs to then do an Ajax call over to octa. This is going to allow that call over to this octa org. So we're going to set that up, just click on save. And then there we go. I'm going to sign out, by the way, as it says in the instructions. And the reason is we want to go through this from the standpoint of actually doing primary authentication when we test it out. All right. So I'm going to go back to my window here running the application. I'm going to do a control C to stop the application, stop the web server. And I'm going to install octa's auth SDK for JavaScript. And then just do an octa repository or octa account on github auth.js at 4.7.2-save persisted. All right. So I'm not sure we know we wrote or whatever we updated these a few weeks ago. I'm not sure what the latest version of the auth SDK is, but 4.7 is pretty much pretty close to the newest version. But you can find out more about this by simply going out to github.com slash octa. And then what you're looking for is the auth SDK. You can also find more information about this at developer.octa.com. Just go to the JavaScript page for more documentation. All right. So I'm going to kick this off. This is going to download the auth SDK for JavaScript. This one will not take too long and should be good. All right. There we go. Okay. So now that I've done that, I'm going to return back to Adam and start to do some uncommenting and just kind of walk you through what we need to do. So within here, we're going to import the object for the auth SDK for JavaScript. We'll be using that later. Down here, I'm going to uncomment all these lines. So in our case, each of you has a unique org that you're going to be assigned. In my case, mine is 217000.octaPV.com. And so what we're going to do is we're going to identify our unique domain for our octa org here. So where those requests to slash authorize are ultimately going to go. Now, we also have this reference to the authorization server. This is going to be used for the issuer. And the reason that we have this as a separate constant is because within octa, you can actually have multiple implementations of authorization servers. So we need the base domain name. But in our case, we're using the base authorization server. So it's going to match our unique domain. But like I said, in octa, you could have multiple of these. All right. The authorization URL is that front door. That's where we're going to initiate the request to obtain the tokens. Now, in our case later on, we're going to set up a environment variable called octa client ID. And so when we set that up, we will then propagate in this constant, the client ID there. For the redirect URL, once we launch this, we're running on local host 8080. And this is just going to take whatever that current value is, and then say that our redirect URL is going to be token callback. And we're going to communicate that up to octa. Remember, we enter that in when we defined our open ID connect application. The scopes, remember, we talked about how there were standard open ID connect scopes, which define what identity information we want returned from octa. So in this case, open ID profile and email are the ones that we chose. One of the things we do in the full one day class is we do in the one day class, we do both workforce identity scenarios and customer identity scenarios. And for customer identity scenarios, what we do is we use the octa sign in widget in order to authenticate users. That's what this is here. We're not going to do it. We're just going to leave the default here workforce identity mode equal to true. I'm going to go down to my list of variables. So within here, the state is used to capture what the user requested in the application so that the user can end up in that location once they're done. So imagine you're in an application, you go to a specific record, maybe someone sends you a link and an email. You want to be able to maintain that state so that after you request the token, you end up on that specific record in that application. And so that's the purpose of the state, similar to the relay state in SAML. The grant type and the response type are referring to the grant type is the flow type or also referred to as a grant. And then the response is what we're getting back. Now, here's the thing. We have a little bit of logic here. And what we're doing is we're saying if this browser does not have the crypto support for generating the, you know, basically the public private keys for basically generating a hash and sending it up to Okta and then sending the seed data later, it basically is a mechanism by which Okta can verify the origin of the request. So if you think about going to the authorized URL, the purpose of Pixi is that when you go to the token endpoint, we can use the generated hash and the seed value in order to confirm that the requester of the token was also the originator of the request. In this case, what we're doing is we're saying, okay, if we do not have those crypto libraries available, we're going to use something called the implicit flow. In our case, we're using what you should be using, which is the opposite use case here, which is the authorization code flow with Pixi, proof key for code exchange, which means we get back to temporary authorization code and we go through those extra steps in order to request the tokens. The great thing about this is that the Auth SDK for JavaScript is going to take care of this for us. So you really don't need to understand all the gory details there. Basically the default mode that runs in. So what I'm going to do is I'm going to instantiate this Okta Auth JS and so it's going to use our Okta Auth class in order to create this. What we're doing is we have a few of these parameters that we're initializing. One of them is that we're going to store the tokens in session storage rather than local storage and then we're going to set the grant type, the URL, the client ID, the redirect URI, the issuer, the authorized URL, and then whether or not we're using Pixi all based on those settings that we set up up there. Okay. All right. Let's see here. Our next thing that we're going to do is in here retrieve tokens redirect. Let me just go in here and do. So we're going to use the Auth SDK and what we're going to do is we're going to get with redirect the tokens. All right. We're going to send a couple of other parameters here. Response type is equal to the response type variable that we set up above. Then we're going to do scopes. It is going to be set to the constant we set up above and then the state is just the state this is used to track what the user originally requested. All right. So I'll talk about this in a second, this retrieve tokens redirect, but this is going to get called by the router when the user attempts to access a protected area of our application. All right. So what I'm going to do is I'm just going to save this and then go into the index.js for the router. I'm going to add a new path in here that's basically going to say, just do this, retrieve tokens redirect. So when a user requests from the base URL, what we're going to do is we're going to call a JavaScript function of the same name, retrieve tokens redirect, like so. Okay. Put a comma on there. And that way we wouldn't add another one. We'll break. All right. So now that I've done that, let me save this file. So when we do this request to slash to retrieve tokens redirect, this calls the function. The function is going to use the SDK to redirect the user over to octa with all of these parameters set according to open ID connect to request the token. All right. Now I'm going to go back in here to my command prompt window set octa client ID equal to and what I do is go in here and grab this, make sure I got the latest greatest control C, go back in here and do an edit, paste, paste that in and set up that environment variable. Double check in the spelling. That all looks good. So I'm going to do an mpm start like so and start up this application. All right. So now that I've done that, I'm going to test this out. Notice that I am currently not logged into octa. That's fine. I want to show authentication. So I'm going to go here and update this to be retrieve tokens redirect. Okay. And so what's going to happen is this is going to call that function, redirect me over to my octa org. And so this is a request that was made up to the authorized endpoint. And now what I would do as an end user is I would authenticate octa training, train me for three, two, one, like so. So I just want to there it is. And then click on sign in. Now what's going to happen is that octa after authenticating me is going to generate the token and return it back to me. Now, like I said before, there's something called the temporary authorization code. That's what we're seeing here. This is a part of the pixie standard. But right now, I'm not seeing any data. And the reason I'm not seeing any data is that I have not yet implemented my redirect URL. So I've requested the ID token, but I'm not doing anything with the ID token. Okay. And that's what we're going to do in our next lab. All right. So in the final lab, what we're going to do is we're going to go in here and implement this token callback function. And we're also going to create a route associated with it. I'm going to create a variant here called URL. And so the idea here is we would capture wherever the user's original request would be going to. And let's just do a location. There we go. We'd use that to track the state. And what I'm going to do is that I'm going to use a function here. So store tokens from redirect. And the idea is what this does is this will basically store in session storage, the tokens that we get back. So I can hear while I set the state before I do that. And then finally, we're going to send the user to where they originally requested. Okay. All right. All right. So now that we've done that, essentially, when we get what this does, this contains the logic that our SDK is going to go, okay, we either we get back the tokens directly or the temporary authorization code. Regardless of which one we get, we're going to use that to complete the process. And once we have those tokens, we're going to then store them in our case in session storage for this browser so that we can use and display the tokens later on. All right. I'm going to do a control cast. I just realized actually I'm not quite done. To fetch the tokens, we would use the token manager. I'm going to go in here octa auth js token manager. Get the token like so. And let's do this. Save a little bit of time here. And the second one that I'm going to grab is the access token. And as you stick around for our next session on doing API access management, we'll be working with those. All right. So let me do a save here and then go back to my router. And the reason I need to go back to the router is that I need to now set up the path or the token callback. Do you like so? Token callback. Should have the same name. All right. There we go. Okay. So let me save this. And then what I'll do is I'm just going to go back here and go into my application. All right. So one of the things that, you know, you can use a site like token.dev. There's instructions for taking a look at your token later on. But what I'm going to do is I'm just going to open up the Chrome Dev tools just for the purpose of being able to see the token that we request. So I'm going to go over here to application and then go to session storage in order to be able to see, you know, if I generate a token, you know, am I going to see it here? All right. Now, later on, or once we do this, we should see this and it should show up and we shouldn't get in the errors. All right. So let me go back to here. Now, the thing is I'm already logged in to Octa, right? So I already authenticated within this browser. So I have a session. So now when I go to retrieve tokens redirect, what's going to happen is this is going to do single sign on. It's going to automatically return the tokens that I get back. Let's go back to here token storage. All right. So what's going to what what just happened is because I already had an active session with Octa, I did not need to do primary authentication again. And what I got back down here was I got back me just do this, my ID token. And so if I take a look at all the claim data in here, here's our token. Okay, here's our ID token with all that identity information and the different claims that we talked about previously. If you want, you can also take this, go out to token.dev, which is a website that we have. And you can take that ID token and paste it into basically a field here. Go down here, this JWT string, paste that in. And so you can now go in and take a look at the token, just seeing the raw A64 decoded data for that token. Okay. All right. That was it for my demo. And what that means is you now have the opportunity to do this on your own. Hey, Chris. Yeah. Sorry to interrupt. It's Mel. Because we have a more manageable group, we're going to actually stay in this main room. So we're not going to go into the breakout rooms. Okay. Awesome. All right. Then what I'll do is I'll stop sharing. Does that sound good? And then we'll just jump into it. Great. We'll share the link by chat for the credentials. And everyone can just go in and you'll be able to download the link or click on the link. Hey, Mel, can I interrupt you? Sorry, Chris. You have a couple of extra slides, I think, for the... Oh, I'm sorry. Oh, I'm sorry. Yes. Yeah. Let me just wrap things up. Oh, no, it's my... I apologize. So let me just return here to... So the way that we're going to do this is that we're going to break or we're going to now work on the hands-on labs. And we have a bunch of people here to help you out. But when we do this, I just want to point out that we do have a class that you can take. If you want to get additional, you know, more of the one-day cover things like customer identity situations, we have a class you can take. And we'll be sharing that link to download the lab guide with the step-by-step instructions through the chat. And then I just want to point out that... So I actually already talked about it, but the name of that class is Single Sign-On Enable Custom Apps and Sites with OpenID Connected as a one-day class. We also have a class called Customer Identity for Developers. This is a class that's on Okta's APIs, which are not necessarily standards-based. So when you think about doing multi-factor authentication, when you think about managing your org via API, when you think about doing things like user registration, those are the kind of APIs that we talk about in the Customer Identity for Developers class. In addition to a number of other topics such as inbound SAML, social authentication, working with inline hooks and event hooks. So it's really kind of the catch-all for all of those APIs that Okta provides that allow you to really, you know, take advantage of all the capabilities of your org. There's also securing your APIs. So the name of that class is API Access Management with OAuth. That is a one-day class also. And so for those of you who are sticking around, we're going to give you a taste of that class or the secure your API session, which is after this one. And then finally, securing your infrastructure. We have a very cool integration with Terraform. And so our very own Brotbot did a session at Octane called the new developer experience at Okta. So if you're interested in using the Terraform tool from HashiCorp, which basically it works with the Okta APIs and metadata configuration files in order to automate, you know, the classic things that you would do in DevOps. So if you make a change, let's say, within a preview environment, you want to automate moving that change into your production environment, you can use Terraform in order to do that. And so Brot has a session. It's going to be on our Octane website. If you were not able to watch it during the last three days, like I said, check out our YouTube channels in order to locate that. All right. So when we do the hands-on labs, we're not going to do the breakout rooms because we only have roughly about 20 people. We thought we'd have a lot more. And so our lab assistants are going to share unique credentials for you. And then the thing is, because people are going to go at different paces, when you're done, you're done. So some of you will take 20 minutes to do this. Others of you will take maybe an hour. Don't worry about it. Go at your own pace. And then when you're done, go ahead and sign off. And I just want to say thank you very much for watching. And yeah, if you have any questions, we have lab assistants to assist. I'm also going to assist. So thank you very much for attending. Let's jump into the hands-on portion and let's do this. Welcome back. Hope you enjoyed that walkthrough of the lab. And we have some time now to help you through it if you are trying this on your own. Otherwise, we are here to just answer questions for the next half hour or so until our first demo of the day. So yeah, let us know in the chat. We are live on YouTube as well as Twitch. Let us know in the chat if you have any questions. Actually, I'm curious if anybody is going through the lab right now. Let us know how far you've gotten on that. Hopefully, seeing Chris walk through it live was helpful. And things are a little bit different if you're doing it from the YouTube and Twitch versions since you don't have access to the VMs, obviously. But the actual content of the exercises should be the same anyway. One thing I would say is if you're not a usual JavaScript user or Node.js user, there's a bunch of online platforms that aren't affiliated with Okta in any way. But one that comes to mind is Code Sandbox. You can do all of this from your browser if you want to. Yeah, that's a great point. Josh says, I already got through it walking through with Chris. That's awesome. I'm glad you made it through then. Yeah, I know this was a JavaScript demo, but it's definitely all the same concepts still apply regardless of what language or framework you're using because it is standards-based. So Josh is an overachiever, thanks. Yeah, Josh, I appreciated that too. The Y-O-I-D-C versus SAML, that was a good comparison. I know there's a lot of questions about which one is the best one to use and when. And it's at this point very clear that Open AD Connect is the future-proof path forward at this point. And SAML is there if you really need it, but it's not the first tool I would pick up out of the toolbox at this point. Yeah. We get this question a lot with customers just about SAML. A lot of customers come to us having already used SAML. And one of the first things we ask is, well, are you planning to build any sort of backing APIs or anything to kind of microservices architecture or anything to reduce or to centralize your footprint across multiple apps? And almost always the answer is yes. And then it's really a no-brainer because SAML is useful for SSO and probably will continue to be for a while, but it's really not suitable for backing distributed APIs at all. So then you end up having SAML and OAuth anyway. So if you're going to go down that path, you might as well kind of pull the Band-Aid and use OIDC and OAuth and have kind of a single stack solution. Right. Exactly. Oh, there's a question here. How do I get the access code? So actually the thing that Chris was talking about, that was for the people who are doing this live on Zoom, where they're the ones that register ahead of time and are doing this with the instructor-led exercises. So the access code, that was for them to get into the VMs that they're using and all that kind of stuff. So don't worry about that. The labs you don't need to use the VMs or that kind of thing for the guide that you have in the link down below that works for as long as you're running code in your own environment. It just means you have to be able to set up Node.js on your own computer. Any other thoughts or questions about what was going on with the demo that Chris was doing? Well, we can always just chat about OAuth questions and OpenID Connect questions as well. Feel free to drop in any comments down below or oh, Mike and I are just going to start talking about who knows what and we'll see where it goes. Yeah, let's see. So the, I know one question we often get is, do you need OpenID Connect or OAuth? Which one are you? Which one do you need to do for when you're building stuff? And generally, the idea is the, and I think Chris mentioned this during his presentation, but he talked about the idea of token audiences, of who the token is meant to be read by or who its intended audience is. And that's kind of how you can tell whether you need access tokens in OAuth or ID tokens in OpenID Connect. So the audience of an ID token is the client application. So it would be the client ID of your registered application. And whereas the audience of the access token is your API. It's going to be some identifier for your API. And in October, you'll end up with an audience, a sort of default audience that's created for your default authorization server. I think it's like API colon slash slash default or something. But that's meant to be to identify your backend API. And so the, I guess the short answer for which one do you need is if your application is going to be doing an OAuth flow and then making a request to a backend API, that's what OAuth is for. And if your application just needs to learn about who the user is, then that's OpenID Connect. So anytime that the app wants to learn about the user, learn their name, email address or anything about the user, if it's the application learning information, that's where you need to get an ID token and read the data out of the ID token. And this is another confusing thing, which is that access tokens oftentimes are JSON Web tokens. And in October, they always are. But a lot of OAuth servers will implement JSON Web tokens for access tokens, which makes them look similar to ID tokens. And I kind of wish that wasn't the case. I kind of wish it didn't happen that way, because I feel like it's confusing when both tokens look so close to each other. It looks like you can use them interchangeably. But they're really not at all the same kind of token. They're four totally different things. They have different security properties based on these considerations. And you really can't mix them up. And even though it looks like they're kind of close to each other. Yeah. I don't know if I could you see any other common questions about this first half of the labs, the OAuth client side of things? Yeah, you know, we've definitely gotten the question about, like people, customers or people starting to work with OpenID Connect will come to us with a little bit of knowledge and say, you know, I kind of get the difference, or I see the difference between OpenID Connect and OAuth. Really all we care about is SSO. So I don't want to have to deep dive into OAuth. I just want OIDC. And we kind of say, well, you know, OpenID Connect is this thin layer on top of OAuth. So you need to you need to know a little bit about OAuth, even if you're not going to have a backing API, even if you're just using OpenID Connect, because it inherits so much from OAuth down to the types of flows that you use. So even if you're only use cases SSO, you're going to have to get, you know, a little, a little ground on it. But, you know, part of what we try to do between the examples we have and the octa CLI and other tools is to make it so that as a developer, you can just kind of drop it in and, you know, ramp your knowledge as you go. But you know, we don't want we don't want a deep knowledge of OpenID Connect and OAuth to be a blocker either. So trying to strike a balance there. Yep. Yeah, for sure. This is a good question from from the chat. If you're building a client app Angular, is there a benefit of using the widget over domain login? Do you have any thoughts on that, Micah? Yeah, that's a great question and a fair one. You know, and I certainly have a bias, but I think it's I can back it up. And that is, there is a there is a benefit over the kind of the redirect flow, as opposed to having an embedded widget. And in fact, the it's kind of the same thing when you do a redirect, it's just a hosted version of that same widget. So there are just there, there are some other benefits, you know, for developers where you don't have to worry about having the latest version of the widget, you don't have to worry about updating it, grabbing it from the CDN. If you're using the redirect flow, and it is the same exact code, it just happens to be running elsewhere. But you know, you have kind of an authoritative guarantee that your application doesn't need to handle or collect or properly worry about credentials when you're using a redirect kind of flow. And from a purely security best practices perspective, that's kind of where we land. And I'm as a developer, I'm really happy about that. I don't want to have to deal with, you know, in the world of Java, you know, this this password that somebody just put in that I now have in my back end as a string, when is that going to be garbage collected, and have to worry about those esoteric little details, because my app never sees the password, which I appreciate. So it's kind of a long winded answer, but I would definitely favor a redirect kind of flow over the embedded widget. Yeah, the question was actually the opposite, right? Is there a benefit of the widget over domain over the redirect flow? And, and you're saying that actually the redirect flow, it has a bunch of benefits, which I would agree. I think that's I think it's a really good point is the more you can kind of offload out of your app, the less things that can go wrong with your app and the less problems that can cause. So, you know, keep keep all the security stuff out of your app, make it octopus business to deal with it. And then you just have less risk and less failure points. Yeah. This is a great comment from Josh, the terminology of primary authentication and federated authentication helps clarify some of the single sign on concepts. Yeah, I agree. The primary authentication being the place where the user is actually typing in their password, whereas federated authentication is the idea of landing at some app after having done a single sign on flow. I think that's a good a good point is that I know this is a lot of I get this question a lot when I when I talk about this stuff of I talk about the OAuth flow and, you know, the application redirects to the OAuth server and then the user has to log in there. But that step of the user logging in doesn't actually have to be them logging in or doing primary authentication at that step either. That could also be federated out to some other service. And you see this a lot, right with with any corporation that has a Google domain or Google org, they call it Google work work space. No, I forget the new name. They change their name every two years. Whatever the Google apps thing is for your domain is called. Now, if your company is using that and if your company has their own single sign on solution like octa, you'll go to Gmail, click log in, and then you don't even get a Google sign in prompt, you get redirected to your company single sign on. But any app that's doing log in with your Google account ends up with Google issue tokens not octa issue tokens because the octa single sign on bit is totally separate flow from whatever client is being logged into. And that's another great architecture pattern here that you get when using OAuth when you connect is you end up with these sort of different segments that don't really have to be aware of each other and everything just kind of works without a lot of special casing as code. Yeah, just for fun, you might open up the developer tool sometime if you have one of those complex federated flows and you might notice, you know, like a half a dozen redirects that happen very quickly, but you're going through all these different systems along the way. Yep, yep. Here's a question from Juan. I know this is web centric, but what do you recommend when it has to do with desktop apps or command line that a user has to run in a PC? So this is actually the OAuth flow is kind of designed around web based applications, but it doesn't actually require to be running in web based applications. And we, you know, first saw this with mobile apps where mobile apps want to be able to do OAuth, so there is a way to do it in mobile apps. And it turns out actually works the exact same way as long as the app can handle the redirect. The trick for in all these cases is the app has to be able to grab the redirect back from the OAuth server. So on mobile, the mobile app can either claim a HTTP URL pattern or a custom URL scheme. And then in a command line app, it's or desktop, it's similar as long as you have a way to grab the redirect, it can work with the same flow. So on command line, you have a couple of options. You can spin up a local web server inside that command line app, which listens on like local host on a random port and use that as your redirect URL, so that when the browser lands back at that URL, it's already able to be accessed by the command line app. Or you can do if you can't spin up a local web server for some reason, you can sort of do a manual version where you make a redirect URL that is actually a web page that like displays the authorization code from the redirect URL and then tells the user to copy and paste into the command line app so that the user has to deliver it. That's definitely not the ideal solution because it's a long copy and paste thing that the user has to do. But if you can't spin up a local web server in your command line app, you can do that version of it instead. But in either case, it's the same OAuth flow in both cases, like regardless of how that ends up It makes sense. Yeah. This is a question about, does Octo support Paceto and macaroons for tokens? I'm assuming you saw Brian's talk, was it Brian? Yesterday talking about the different token types. Yeah, yeah. That was a great session. I learned a lot and I also have more to learn about macaroons apparently. A lot of that went over my head. But yeah, different types of tokens for different purposes. But no, Octo's access tokens are JSON web tokens. That is a standard for access tokens and it is well-established and because it's a standard, there's good library support and things like that. I think Paceto and macaroons are well, macaroons, there is no spec as we learned yesterday. And with Paceto, it's still pretty new. So I think it's going to be a while before we see large vendor support for that kind of thing. It is supported on token.dev though, at least the Paceto side. Oh yeah. Yeah, that's a great point. That's a nice resource. Token.dev being the sort of testing tool for tokens. Yeah. Yeah. How popular are JWE tokens? Probably, what's the main scenario why this might be a requirement? So JWE versus JWE would be the when your token is encrypted rather than just signed. And I don't have like any solid numbers, but I feel like I haven't seen JWEs very much at all in the wild. Like I feel like most of the times the vast majority, there are people are using unencrypted JSON web tokens. I'm not entirely sure the reason for that. But as for when it would be a requirement to use JWEs, the fact that JSON web tokens are unencrypted basically means anybody that has one can read the contents inside it, even if they can't verify it. So if you think about ID tokens and access tokens, those are going to land in your client application, which might be a single page app in a browser or might be a native app in somebody's building. And in both those cases, the actual end user, as well as potentially the app developer, well certainly the app developer for when they're testing it, they will be able to see what's inside of those tokens. And obviously, the app developer is meant to see what's inside ID tokens, so we don't really need to encrypt those. But app developers do not need to and should not look at the contents of access tokens that's only meant to be consumed by the API. So the problem is that app developers and users can see that data when it's not encrypted. So if you have things in your token that are any kind of sensitive information or information that you don't want the user to know about themselves, that's when you would want to go to an encrypted token. The example I'd like to use is if you're building something that a system that has the concept of shadow banning users, where the idea of a shadow ban is that users are effectively banned from using a system like they can't leave comments on things, but you don't want them to know that. You want them to still be able to do the comment operation, see that it worked, but then nobody else can see their comment, right? They're kind of in like a little hidden box out of the way and nobody can tell that they're nobody else sees their content, but they don't know that they're banned. And in order to do that, you could put a claim into a token saying that this user is shadow banned. But then because it's a JSON web token, the user could find that out about themselves, which would be defeating the purpose of the shadow ban. So that's the problem there. And that's when you would want to go to an encrypted token format so that users can't see inside the access token. Yeah, I think part of the challenge with JWE is that the spec includes a lot of different encryption algorithms, and some of them are pretty challenging, a lot of the elliptic curve algorithms. And just anecdotally, I contribute to the Java JWT project, JWT, and we're very close to our 1.0 relief, which will include JWE, but it's taken us a year to really flesh out and make sure that we're spec compliant and covering all the different types of encryption algorithms that are included in the spec. So it's a lot more challenging to go from JWS to JWE. Signing is pretty straightforward and I think better understood at least at this point. Yeah. All right. Well, that's all the time we have for questions right now. We're going to take a short break and come back with Matt Rable doing a demo of J-Hipster, and that'll be at the top of the hour-ish. I think we'll do a 10-minute break. Come back at the top of the hour with a demo, and then we'll be back, Mike and I will be back with more Q&A and chatting about all things OAuth and OpenID Connect. So see you back here shortly. Same stream. This stream is going to keep running the whole day, so don't worry about finding a new link, but we will take a short break and see you again. See you back here soon. All right. See you in a little bit. Rable, I'm a hick from the sticks. I grew up in the backwoods of Montana with that electricity running water, and here I am today doing all this computer stuff, so anyone can be anything. Today I'd like to show you J-Hipster. Hopefully you're here and you haven't heard of J-Hipster because if you haven't, then I got a lot of good stuff to show you. If you haven't, you're just a fan. Well, it's nice to have you and good to see you. If you have any comments or any questions, please post them in the comments, whether you're on Twitch or they're on YouTube. We're streaming to both, so love to hear from you. So J-Hipster is a development platform and application generator that makes it easy to get started with many of the leading frameworks in the Java space as well as the JavaScript space. So that's why we call it hipster because we're Java people that are into Angular and React and View. So that's not always that common. So what I'm going to do today is do my infamous or famous, I'm not sure, blog demo. So I'm going to create a blog and instead of using JWT authentication, which is the default for J-Hipster, I'm going to use OAuth. So what I've done is I've created this J-Hipster 7 demo. You can see there's a GitHub repo here and there's nothing in it yet. I'm not going to upload the code until I do a bit more polishing, but I do have this demo script that I will use. So if I pull that up raw, you can see an ASCII doctor there. And what I'm going to do is I'm going to put that on the left. So these are all the various steps that I will use to create this demo. And then I will also be using IntelliJ Live templates for something. So if you see me just type a few characters and it spits out a bunch of code, that's not really me being fancy. It's just IntelliJ pre-recording my setup. So we'll start by opening up a terminal here, put that on the right. I do have the latest version of J-Hipster installed. You'll see that's 7.0.1. I'm using MPM version 6.14 and node version 14.15. So I'll start by creating a blog directory. I think I already have one. So let me move that one to blog.back here. And then I'm going to use the take command. Take actually does a make their ANACID. So we'll do take blog. Now we're in that directory and I can type J-Hipster. So J-Hipster will prompt you for a number of options. And you can see down at the bottom here it says this monolithic application of gateway or microservice. So obviously microservice has many different parts and many different apps. So I'm just going to do one of the simplest way possible because if you're new to J-Hipster, I want to show you an easy way to get started. So we'll just do a monolith application. I'm not clicked on there. So there we go. And we're just going to call it blog. And we could make it reactive with Spring Web Flux, but for this demo I'm not going to. The one cool thing about Spring Web Flux is it makes your backend so it can utilize your hardware more and you can get more throughput and therefore you can lower your cost if you're in a cloud environment. If you don't have more than 500 requests per second, then you're going to get the same performance from Spring MVC as you do from Web Flux. So for this particular example, I don't expect this blog to be that popular. So I'll just go ahead and say no. Default Java package will do org.J-Hipster.blog. And then like I said, instead of using Jop authentication or JWT authentication, I'm just going to use OAuth2 and OpenID Connect. This is all powered by Spring Security. There's nothing in here that's octa-specific or keycloak-specific. This is just the power of Spring Security making OpenID Connect possible. And then I'll just do a SQL database. Production will use Postgres. And for development, we'll use H2. And then which cache? I'll just use the default EH cache. And then, yes, we'll use Hibernate for the second low cache. I did a poll yesterday on Twitter. It's still going if you go out to twitter.com slash M-R-A-I-B-L-E. And it asks what I should use for this particular part, Maven or Gradle. Maven's currently winning by almost two to one. So I'll choose that. You want to use a J-Hipster registry? I'll say no because not really doing microservices. So I don't really need it. As far as other technologies, I'm just going to say nothing. And then I'm wearing an Angular shirt. So I'll use Angular. Do you want to generate the admin UI? Sure. And then boot watch theme. I'll go with the default. And we'll go with internationalization support with English. And then go down to Spanish here. Like that. And then for e2e tests, we'll use Cypress. And then it asks if we want to install other generators from the J-Hipster marketplace. I'm going to say no. If you said yes, then it would prompt you for, you know, give you a list of all the different ones. So now you see it's creating a whole slew of files for us. And not only is it actually generating files for the UI in the backend, but it's also generating tests. So if I was to run this through Sonar, this actually ships with the Docker container I can use and test it with Sonar, you would see that it has about, I think, 70, 75 percent test coverage throughout, not only on the backend with the Java stuff, but on the front end with the TypeScript that's used by Angular. And the most painful part of this all is, of course, MPM install. And there was a point in my life when I was first starting with Okta where they actually provided me with a laptop that was very locked down. And I remember doing this at DevOps UK. And this process here took like eight minutes. So you can imagine me dancing on stage and being like, just waiting for this to finish. This should only take about a minute or two. And the reason that it was taking so long was Okta was actually scanning any new files I created on my hard drive. And so since then, they've made it so I have this particular place where it's okay for me to install files and everything works okay. So once this is done in writing, what I'll do is I'll start up KeyCloak because we're using KeyCloak by default in a Docker container. And then I'll run the app and we'll go through and look at some of just the default features in the UI that's generated for you. I'm almost finished. Oh, now it's got a download Cypress. These are those times when I wish I had a fiber connection, you know, one gig. I live out here kind of south of Denver now in Colorado. And the place we lived at before was kind of central Denver. And about six months before we moved, we got that one gig connection. And man, that was awesome. And now I think we're 80 megs. So not super fast, but hopefully this will be done pretty soon. Zero vulnerabilities, right? That's good to see. Always like that with any open source library you're using. And so you'll see that took about four minutes and 38 seconds, which is way longer than usual. But also a lot of that time was me, you know, entering in those values in the beginning. So, you know, maybe a minute or two and you can see we're a platinum sponsor on the project. We sponsored J-Hips through with love. So I'm going to go ahead and start it with MVNW here. And if you're not familiar with the Maven wrapper, that is now included as part of the Maven project. And fun fact, Brian Demers on my team at Okta actually wrote the first version of the Maven wrapper. So we have a lot to thank him for there because it makes it so you don't actually need, you know, Maven installed on your system. And my friend James Zord actually wrote a further enhancements where you could actually download a JDK and install Maven. But I don't think that ever made it in. So that would be like super convenient for no one, you know, not even having Java installed here. I do have Java 11 installed just to let you know. So you can see it there. I did try this with Java 16 yesterday. And what I found was there was something in J-Hipster.xml that prevented that. So if you look for 16 here, you can see you're running an incompatible version of Java. So this has to be changed to 17 if you do want to, you know, use it with Java 16. And I did commit a patch for that yesterday. So everything will be working with the next release with Java 16. No problem. Okay, so this is a error that I did want to show you because you might run into it. So what's happening here is that it's unable to connect to Keycloak. So it expects Keycloak to be running at this URL, and it's not. So if you do, we'll clear this, ls-source-main-docker. You can see there's a number of Docker files we can start up. So not only the app itself can we run with Docker with this app.yml, but also Keycloak. So monitoring if we want, the J-Hipster control center, and Postgres if we wanted to run it with a production profile. And so now if we wanted to actually run against that and see how many, you know, what our test coverage looks like. So this Realm config right here is used by Keycloak to import the default users and app settings for OIDC. So I can do J-H Keycloak up. Here's a command shortcut that I have. J-Hipster has O my ZSH plugins that you can use. So you can have a bunch of shortcuts for Keycloak and all that. So now let's see if it's routing Docker PS. Looks like it's starting up. So we'll try this again. And you'll see we're also using Spring Boot 2.4.4. So this is a big milestone personally for me because J-Hipsters seems to have lagged Spring Boot by about six months in our implementation of what Spring Boot offers. And now we're right up to date with what they offer. So that's pretty exciting with version seven. And there's also some fake data that'll be loaded and I'll show that after I start generating entities. But right now we're waiting for Webpack again. I do think this is an issue we need to fix. I do believe it's actually fixed with Gradle, but not so much with Maven. You notice I already built the project and started it up. So why is Webpack like rebuilding everything again? Right? That's silly. Come on, Webpack. You know, it took 23 seconds of my day right there. But with Gradle it's got like a files updated check. So it can actually skip that compilation the second time. So now everything's up and running. And we can go ahead and open in our browser. We'll make that a bit bigger. So you can see if you sign in, it'll redirect you to Keycloak. And then you can just use the admin admin that we have set up by default. And if we go to entities, there are none. And if we go to administration, we can see there's a number of metrics. So it's doing timings on the different requests, data source statistics, cache statistics, all that, as well as a health check. So you can see our disk space. We have quite a bit here. I got 150 gigs free. And we were to look at the configuration. You can see all the configuration that is used for J-Hipster and Spring and all that sort of stuff. You can even go into the logging and change the logging. So for instance, if you were to search for org Spring framework, and you wanted to change, you know, it's AOP to info, you could click right here. This is more of a feature of log back than J-Hipster. It will actually change it on the fly and start logging differently on your back end. And then if we were to go to API, you can see our swagger UI. So if you want to have some developers working on the back end, some working on the front end, on the front end, just want to see the API available, they could go here. And of course, they can execute and get commands back. It also spits out curl commands. So that's pretty slick. And all works pretty well. So let's go back to our demo steps here. We'll put that back on the left. And we'll go ahead and stop this, clear it out. And what I'm going to do is import a blog JDL. So JDL stands for J-Hipster Domain Language. You know, we're hip if we have our own domain language, right? So start.jhipster.tech is where you can go for that. So let me open that up. That bigger. And then I'll sign in here. And I don't know my password, but one password does. Oh, J-Hipster online. I got a couple of counts. And design entities is JDL Studio. And what this allows you to do is actually write JDL and see what it looks like. So you can see my JDL on the left here. I have a blog. I have a post. And these are, you know, the properties within that. We have a name and a handle. It's required. It's got some validation rules. And then you can even make this bigger if you want to see how all the relationships work. It's got a post with a title, a content, a date, and then a tag, right? Because you want to have tags on your posts. And it's also got relationships. So if you've ever done much with Hibernate or JPA, you know that those one to many and many to many annotations can get a bit confusing. I think this is a little bit easier to use with our relationship, many to one and many to many. But just like with Hibernate and JPA, I'll admit I copy and paste a lot of this stuff because, you know, once you figure it out, once you like to use it again. But basically this syntax here says, you know, there's a relationship of blog to a user login to user. And that user and login in the braces is actually saying that that's the field we want to display on the drop down when the user sees it on the UI. So we can go ahead and copy this right here. And I'll go back here and I'll do vi blog.jdl, put that in there. Screens like darkening, hopefully that's not darkening for you. Brightness, come on, baby. That's what happens when you do full screen terminal, I guess. So get out of full screen, make that a bit smaller there. And then you do jhipster, jdl, blog.jdl. And this will generate entities, both in the back end and the front end. And by default, we use Liquibase to create your schema and to migrate your schema. So if you want to, you know, make changes and make your back end have new fields or remove fields, Liquibase will handle that for you with your database. So as part of this process where it's actually creating new entities, it's also going in and creating new Liquibase files that will create new tables for these entities. And then I'll go back to my demo instructions here, put that on the left again. So I'm going to restart the application. Someone's calling me from Cambodia. Hi, Cambodia. Never mind. You know, that's a scam call. In fact, like 95% of the calls I get these days are scam calls. I'm thinking of just deleting like the phone app off my phone. I really don't use it that much. So this is again, you know, rebuilding stuff. And we do have a way. I'll show in a minute where you can actually have the front end, like be smart enough to recompile. And we do do use spring boots developer tools on the back end. So if you did recompile a file, it would actually restart spring boot as well. And that works most of the time. So you can have a pleasant experience for the most part where all you have to do is save a file or recompile it, and then it will reload it. And of course, if you're using Eclipse instead of IntelliJ, if you save a file and reload it, right, IntelliJ, I think you have to, you know, change some things to do it. And then it'll work that way. So here we are, starting up. Come on, baby. Talking to Keycloak there. And then we're back up and running. And we can make this bigger again. Now you'll see we have some entities, right, and we have this fake data under here. And the reason that we do the fake data with faker.js is because as developers, it's kind of a pain even for demos like this to actually relate things to each other. So it's kind of nice to have this fake data here. So I'm going to take a little detour from my demo script and makes things easier. Instead of deleting this fake data and restarting everything, I'm just going to go ahead and use it. So I'm going to assign this to like the admin user here. And we'll give the admin user a couple blogs. And then we'll give the user, regular user a couple blogs. Oh, this is a, this is a kind of a thing that I would like to fix with J hipster. So right now what happens is if you log in from an IDP using OAuth identity provider, what happens is that user is then saved in the database. So you'll notice we only see the admin user right here. Instead of the admin and the user, which are both in Keycloak. And so I actually have to sign out and then sign back in as the user in order to see the users in that drop down. So if I were to, now I see user and I can do that. So one solution I've seen for making this better would be to use skim, which is a standard protocol to be able to sync users between your identity provider and the actual application that you're using. So that would solve this problem that we're not just saving the users when they log in. What I found is Keycloak doesn't have support for skim to write quite yet octa does. So that may be something we add in the future. But now you can see one of the problems here is everyone can see everything, right? And if we were to go into the posts, you would see that we can assign some of these to different blogs. So was that first one integration? Maybe we should probably change the names of these. So go into blog here and change this one to, you know, admin's blog. And then change this one to like user's blog. We at least know what they are. And then if we were to go into posts, we could see that, you know, we can assign this one to the user now. And we still have a problem, right? We can see everyone's stuff. So how we're going to fix that is basically go into one of the Java files and change it. So instead of getting all the blogs, it finds the blogs by current users. And then we'll show how those blog list screens limit that data. So I'm going to open up my IDE for this. IntelliJ is my favorite. I used to be a huge eclipse lover, probably from like 2002 to about 2006. And the biggest reason I loved eclipse was it was just so much better and faster than everything else out there. Hi, James. We're looking to get together for copy. Maybe I should turn on do not disturb here, huh? Do not disturb for one hour. Okay. So now while this is loading up, I can start looking for my code here. I need to look for a blog resource, right? That's the rest endpoint. So blog resource, hopefully it's indexed enough that I can reach it. Come on. Yeah, the indexing. Enough with demos, huh? Have a drink. Ask a question. It's almost done. You can do it. I probably should have just like created this in the same directory and then maybe IntelliJ would have faked it. Well, let's try again. There we go. Okay. So now we have the blog resource. We've got to reset our editor. Restore default layout, maybe. Well, why is it only showing the so few lines? Come on IntelliJ, you're killing me. Maybe after it's done. I mean, I say I like IntelliJ and then you do this to me. Come on. Okay. Let's try. Restore default layout again. Nope. Okay. Try killing it and re-opening it, right? Maybe I shouldn't have then upgraded my IntelliJ instance right before this demo. You could say that. Okay. Now it's working. So now we go down to get all blogs. So if you're going to look at the structure here, right, you can see where the methods are and then you see this find all. So we can just change that to find. Oh, it's still indexing, really? Find by user is current user. So now you can see, you know, we will be limiting those blocks. So go ahead and recompile this here. Not going to let me. I want to build, sorry. We compile that blog resource. Should restart everything back here. Come on. Spring depth tools. There we go. And then I'm going to use MPM start. And what this will do is it'll give my front end the ability to restart as well. And so it will do some proxying to the back end and make everything work as if, you know, they're, they're separate. And then you don't have to worry about like cores cross-origin resource sharing or anything like that. So I think it's starting. It's not quite up yet. There could be a problem here. You notice it actually doesn't have those depth profiles in there. So I haven't seen that before. I'll just try restarting it manually there. And I do have 64 gig of RAM. So you think this stuff would be faster, but what I've learned is streaming really slow things down like in an actual conference environment where I've just plugged into a presenter behind me, you know, projector, these things typically go faster. But man, if you run an MPM install on stage, it's always risky. So the first time I actually did a J-Hipster demo was at DevOps 2015 or 16. And I actually pulled this whole thing up in 20 minutes. So it looks like we're going a little over that today. But, you know, the tools got fancier and they got slower. So maybe that's a webpack problem. I do find it funny that actually, you know, webpack takes longer to compile than Java code. Like, what's up with that? So we're still waiting for the back end. It gives us an error, right? It's like, hey, Maven, why are you re-compiling that again? So, note to self, maybe even though the Java community wants me to use Maven over Gradle, I should use Gradle just for the experience because Maven, you keep compiling webpack. And I didn't change anything like you're kind of ruining my demo. There is a way around this. And I will use it the next time. So I'll just show you what the command looks like. It's mvn-p-webapp. And that means don't activate the web app stuff. So the only problem there is you won't get anything rebuilt if you were to hit 8080, but we have everything running on 9000. So it shouldn't be a problem. I'll remember to do that next time. Maybe I should even add it to my demo script there. Okay, so now if we go here, and we're going to log in and look at our blog, you can see now we only have the users blogs, right? And if we were to sign out and sign in and go to admin, admin, then we will have the admins block. So, of course, you need to do some work on entities as well. I'm just going to skip that part because the reloading was kind of a pain. And I'm sure you don't want to see me do that again. But here's what you will do for that. So it's, there's a get all posts in that post resource and no changes fine by a blog user login order by date descending. So we can actually change that code. That's not hard. We just won't actually restart anything. So we go to entity resource, not here. And or post resource, it's called post resource. And I like to name it post resource because post is like an often a keyword, right? For annotations like Jack's RS annotation. So using post can cause havoc in various frameworks. So we're to go to get all posts here, then we can, you know, just take this eager stuff out and be like, we want to do it like this. And then those will be protected as well. So only the current user will be able to do it. And then you'll notice that doesn't exist. So you have to actually create that on the post repository. But that's all you needed to do. And now those posts will be limited as well. So back to our instructions, we won't recompile everything. But I do want to make the UI look better. So if we were to look at the posts, you can see these don't really look like posts very much. So let's go into the post component and make it look more like a post. So first of all, if we were to edit this and, you know, change something, so, you know, we want this in H1, right? We want to put some HTML in there because it's a blog, right? Or maybe markdown or something like that. But, you know, we want to make this big. So people notice. We save that. You'll notice it's escaped, right? So we can fix that with Angular and go down here to the post content. And we'll take this out. And you need to specify an inner HTML. And then you can put the post content there. And then you go back here and it refreshes automatically. And now you see your HTML in there. So that's pretty slick. And then we could even make it look more like a blog and take this whole section out and use one of my shortcuts. And now if we save it, you'll see it looks more like a blog, right? And you can still edit stuff and change them. Or you can even delete them. You know, that all still works. So that's the majority of the demo locally. But I also want to show how you can, you know, put it in production. So this is how you build for production. And then there will be some tests that fail because I added that stuff in. But I will eventually have a tutorial that shows you how to fix those as well. Basically, it's adding a user object to blogs and posts and stuff so they can do that verification. And so I'm just going to go ahead and do Heroku login here. So we'll stop that. And it's your Heroku and deploy to Heroku. So as part of this, it will prompt me to what name to deploy it as. So I'll say day hipster on Friday demo. And then which region and which type of deployment I'll compile it on Heroku. You can use Java 11 all the way up to 14. And then this is pretty cool. It asks you because using a lot to do you want to provision the octa add on. So I can go ahead and do that. I can create a valid user or valid email. And then it does give me a password. So you all have access to my octa org now. And then it basically uses existing get repository installs a Heroku CLI deployment plugin. And then it does all the work actually on Heroku. You'll notice it does prompt you to overwrite your prompt XML. So you do have to say a for all there or you can do it for each individual file. You can even see the diffs if you wanted to. But this does take probably, you know, five or six minutes. So what I've done is I have one here that's already up there. And we can just look at that, like any good cooking show, right? So this is the one I deployed last week. When day hipster seven dot zero, that one came out. Now it is on a free plan on Heroku. So, you know, it probably stopped. I tested it like an hour ago, but it stopped since then. And then I also have one that uses just JWT authentication. So we'll see if we can get both those up and running. And it's a race, right? We have this one going here. And we have those going there. So who's going to win? I think Heroku is probably going to win. Who knows? It's that that darn MPM install. Like if someone could figure out how to make MPM as smart as Maven or Gradle, because they only download the artifacts once, right? And then their version, but MPM like downloads them almost every time. And yes, I have tried NNPM and that doesn't solve the problem, at least for J hipster. It doesn't because J hipster still uses MPM. So this is the JWT one. This is the OAuth one. So we can try OAuth here. You'll see it redirects me to octa there. It's already got my username password. I sign in. I come back. Everything's working. I can see my entities. And there's no data in there because it's production profile. So there's no fake data. And then this is the JWT one. And you'll see you can just use the default credentials and log in that way. So that's the majority of my demo. We can keep watching this one to see if it actually succeeds, but going to do an MPM install for about four minutes. So that might be kind of tough. So we have any questions that have rolled in here? Let's look on YouTube. MPM install is the most painful part always. Yes, it is. It is tough. MPM install on stage or virtually like this is risky at best, but it did work. It's just kind of slow. So I think in an in-person environment like you can have better jokes when people don't have to wait, you don't lose the attention. And Josh was looking forward to the dance. So I got to work on my dance skills. I did make a New Year's resolution to dance more. So hopefully things will open up soon and we can get out and dance more. So where do we go from here, Aaron? Oh, you're muted. I keep forgetting to unmute myself in the string yard. Thanks for the demo. That was awesome. Well, it's great. If there's no more questions about it, then we will go ahead and wrap it up. And otherwise, you know... There's a question that's in Russian. My Russian is not that good. I can still kind of read it, but I don't really know what it says without Google Translate. I hope it doesn't say something bad, otherwise. Right. I just told everyone to hand it off. Yeah. I've been learning even a Croatian and some of the words sound similar, even though Croatian uses the Latin alphabet. Nice. Yeah, I got a degree in it, but it was 20 years ago. So it's funny. I didn't keep it up and I really should have because there's so many Russians we interact with in software development. It would have been a good skill to have. It'd be as good as maybe Kotlin or something. That's awesome. I did not know you'd got a degree in Russian. Yeah. Been a while. Yeah. Well, cool. Thanks for the demo. Let's go ahead and wrap up and we'll take another short break. And I'll be back on with Micah, I guess, in a few minutes. And at the top of the hour, we will come back with Chris Berry's second session, securing your APIs with Okta. And with that, I will see you back here shortly. All right. I'll be in the chat for the rest of the day. So if you have any questions about the answer, hit me up. All right. Thanks so much. Yep. Cheers. Hey, Micah. We are back. Thank you all for joining. Erin and Micah here again to answer some questions for the next few minutes. So we're going to hang out here with you all live. And then at the top of the hour, we will jump into the next lab section, Chris Berry's securing your APIs with Okta. And there will again be a workshop or a lab component to that, which you'll be able to follow along with on your own. And we will provide the links down in the description and in the chat once that starts. But in the meantime, we're happy to answer any questions about Okta or Oath. So drop questions in the chat or just know. So did you have anything you wanted to start out with, Micah, while we wait for some questions in the chat? Yeah, sure. We had a question earlier just about groups and roles and how that could relate to OpenID Connect. It was specifically in the context of Google's SSO server, which I don't know a lot about, but I do know Okta's. So we could talk about that a little bit. Yeah, so Okta has this universal directory where you can manage your users. It also has groups as part of that. You can create free form lists of groups and assign users to groups. And how it then ties back to OpenID Connect is in the authorization server definition, you can include a group's claim either or both in the ID token and the access token, depending on what you need to want to use it for. But in the ID token, then your app can then be aware of the groups that the user belongs to. You can have confidence that you've gotten the right list because it comes in that ID token, which is assigned GWT. And then your application may react to that in different ways. Maybe you have different menu items or different parts of the application that the user can access based on the groups that they belong to. And that's pretty straightforward to set up in Okta's admin console. You go to the custom authorization server and just add in the group claim and then you'll get an array of groups in the ID token. So actually, that's something that I know people are often confused about. And this kind of gets to our earlier discussion about access tokens versus ID tokens. When would you say is a good time for the use of groups in an ID token specifically? Because a lot of times it's going to be your APIs that are making authorization decisions based on what kind of user it is, right, where it's only admins can do these kinds of operations. That's pretty straightforward. Those operations happen on the backend API. So you need that group information in the access token claims, which is not the ID token, right? So if you're putting groups into the ID token, it's implicitly that it means that the consuming app, the OAuth application, is the one that's going to need to consume that data. So what might be some use cases for that, then, of the app actually needing to know groups where it's going to be making decisions regardless of whether the API enforces those policies? Yeah, I think it's a great place where you can get a marriage of user experience and best practices from a security perspective. So maybe your spa app will show an admin navigation menu if the user is in the admin group and won't otherwise. But you don't want that to be the only thing that you rely on. So then maybe taking an actual admin action requires a backend round trip because you don't want people like me who are going to inspect the code and enable disabled elements on the page or hack around to be able to actually do anything. So it's nice to have that group information for things like UX, what you see or maybe don't see. But that can't be like your last line of defense from a security perspective. You have to have that validation on a backend so that you don't have, since we're in an untrusted environment in the browser, you don't want people to actually be able to accomplish an administrative function because they were able to poke around. Got it, that makes sense. So it's more of a hint at that point since the client isn't the one enforcing those permissions, but it can at least be used to inform the UI of the client. Yeah, yeah, I would think that would be a best practice and a good use of say, you know, group membership on the spy application. Yep, yep, makes sense. We've got a couple of questions coming in in the chat. Tags. What objects does octa support those for? You know? I don't actually. Let's follow up specifically not seeing tags on applications so looking for how to relate them to the business area responsible. I don't know the answer to that. I'm not actually sure what objects support tags at all. Is that like a common part of a user profile? I'm not even sure. Yeah, I haven't seen those be used very much at all. I can circle back to that. Yeah, might follow up with you on that later. Here's another question. I would like to start building iOS apps to access my APIs accessible through octa spring boot app. Any past videos that you may have on implementing your SDK on an iOS app? Great question. I am actually not sure if we have any videos about that. I don't know if I know we have some guides and stuff. We have a few posts on things like Ionic that allow you to generate native mobile apps from things like JavaScript. I know we have a few blog posts on Ionic specifically, but I don't know if we have any videos. Oh yeah. Now that you mentioned Ionic, I do see a couple of videos on our channel. So if you search our channel for iOS or Ionic, there are a couple there. However, there's nothing super recent. Oh, it's not true. Matt did one three months ago. Awesome. That's actually this here. And Matt's confirmed that we have some on React Native too. Matt's on top of it. He's got octa CLI and react native in three minutes. There you go. Cool. Yeah, nothing was Swift. I haven't seen any Swift stuff specifically. But that would be that would be a good one to do. I've only done a little bit of iOS development myself. So I don't know if I'm the best one to be like teaching iOS development. But hey, if I can get it going, anybody can. Because yeah, last time I opened up Xcode was probably over a year ago, which means it's horribly out of date. And I'm after download 10 gigs of stuff again to get it to work. Yeah, I hit up Xcode every now and then because, you know, brew or something requires it. Right, right. I think that's the last time I had to download it was for homebrew. Yeah. Oh, cool. Yeah, if there aren't any other questions, then we are going to go ahead and take another break before we come back with Chris Berry session. So again, just to to recap that is going to be a Chris Berry will be talking in Zoom to an audience on Zoom. And he may be saying some things in there that aren't exactly applicable to how you're watching it on YouTube here. So sorry about that. But, you know, that session was full, the Zoom session was full, but you get to watch it now here. And the you should be able to still follow along with the labs. However, it won't be using the VMs that they have running for that session, you'll have to just kind of do it on your own, totally possible. And links for that will all be in the description below. And I'll try to drop them in the chat just in case you're watching it real time as well. So we're going to go ahead and that'll be pretty much at the top of the hour. So we'll take a break till then. And we'll be back for more Q&A after that as well. All right, see you back here shortly. Sounds good. See you in a bit. Once again, thanks for joining everyone. I just wanted to say that we'll get started in a couple of minutes. Okay. So we'll get started very soon. All right. My name is Chris Berry, and I'm going to be your instructor for the next about we'll do roughly about 40 minutes of lecture. And then we'll do a roughly half hour demo of what we'll be doing in the hands on labs. And then after that, you're going to get a chance to do the hands on labs. We are going to provide you with credentials for accessing some remote virtual machines. And then also an octa org to configure in order to secure your APIs with octa. All right. If I make any forward-looking statements, please take them with a grain of salt. Her roadmap is subject to change. All right. If you have questions, here's the great news. We have a ton of octa experts on this call. So I'm going to be busy presenting. And they are going to take on that role of answering those technical questions that you have. Please just use the chat window within Zoom and send a message to everyone. And then the technical experts from octa who can be identified actually, their names all start with octa. We'll do their best to answer your questions. Okay. All right. For those of you who attended the previous session, what we did was we used OpenID Connect in order to do federated authentication. And what we did was we protected access to our application. Now, our application is multi-layered. And what we also need to do is we need to make sure that we protect the back end. And so that front end will make an API call to the back end. And so what we're going to do is utilizing octa's API access management product and the OOF specification. We are going to request what's called an access token and use that access token as a part of our request over to the back end API. We're also going to lock down the back end API. So we're going to use a library provided by octa called the JWT Verifier in order to protect that API to prevent access by that hacker from accessing that API directly. All right. So our focus is on the back end, although we will also work on the front end. So what happens if you don't protect your API? So one of the ways that I interpret the zero trust architecture of octa is when I think about a corporate network, people might have created their own homegrown security measures, authorization logic for accessing systems. And so what we're promoting with zero trust is that you should take a look at implementing internet-grade security even on your private corporate networks. So in this case, and this is very simple in this example where maybe the client application is using HTTP and maybe it's sending over some sort of custom authorization header or what have you. But it's the kind of thing that someone might be able to backwards engineer in terms of once they, if they do violate your network, being able to then access those systems that you made the assumption that no one would be able to access because it's on your private network. So if you don't protect those APIs using standards like OAuth, then you risk that type of penetration attack. Now, when we think about single sign-on versus API access, the single sign-on story that we just talked about in the Secure Your App session was all about having these multiple relying parties where we would do a single password authentication to octa. And then from that point on, we're able to seamlessly access these different applications which are called relying parties where the user would not be prompted for credentials. Now, in this session, what we're going to do is we're going to introduce a new element and that new element is called the resource server. This is the API that we are calling or accessing. You'll notice some terminology has changed in the case of OAuth, we refer to the relying party as the client app and that's because it is a client to the resource server. The end user, we refer to them as the resource owner. And the reason is that OAuth confers responsibility for providing that access to that resource owner. So it's their job to go in and say, all right, I'm going to share data between these two systems. I'm going to allow this or disallow this. Now, when we think about an example, here's a little example that we created that shows OAuth out there in the real world. And so in this example, we have two applications. We have Meetup and then we have Google Calendar. If you've not used Meetup, the idea behind Meetup is that you would use Meetup to find people with similar interests. And what you do is you'd do just that. You would meet up with them at some location. Let's just pretend for a second that we're all coin collectors. And so you would use the Meetup application to find other people in your area who are also coin collecting enthusiasts. Now, after you find, let's say, a local event that you want to attend, let's say it's next Wednesday, it's going to be held at the local Hilton or something like that. In this case, what you would do is you'd say, all right, I'm going to sign up for this event, this coin collecting event. And at that point, Meetup might say, you know what, you could manually go out and create this event in your Google Calendar. Or alternatively, what you could do is you could say, you know what, do you want to give me the responsibility of creating the Google Calendar for you? Essentially, Meetup could automate the saving of the event in your calendar. So the way this would work is the user would go into Meetup, they would sign up for the event, and then indicate that they do want this automation to be performed for them. The user would get redirected over to, in this case, Google, so whatever Google's implementation of an authorization server is, they would get redirected over to their Google account. And what's going to happen is Google might prompt them to authenticate again, especially if they don't have an active session. And then Google is going to say, do you wish to provide Meetup with access to the Google Calendar so that Meetup can save the events in your Google Calendar? Assuming that the user says yes to that question, Google is going to issue an access token to Meetup. Meetup would then use that access token to do an API call over to the Google Calendar APIs and present the access token in the authorization header, HTTP header, as a bearer token. Now, there's a couple of things I want to point out here when we think about OAuth and delegated access. The anti-pattern that we want to avoid is if Meetup wanted to access Google Calendar, Meetup saying, hey, give me your username and password to Google and I'll take your credentials for this other system and use them to access your resources. This is an anti-pattern because now Meetup has your username and password for Google. Let's say Meetup gets hacked. Not only will Meetup be vulnerable, but now this user's Google resources will also be vulnerable. In addition, the Google is going to issue this access token in lieu of credentials. And this access token is going to have a limited set of permissions or capabilities. And we'll refer to those as scopes. So, for instance, the Meetup application only needs to perform a write operation in order to save events in Google Calendar. What they do not need is they do not need read capabilities for Google Calendar. As you might imagine, if they had read capabilities, that would be a privacy concern that this application would be able to see all of the life events that are currently in your Google Calendar. In addition, the access token, unlike your credentials, has a limited lifetime. And so, this limited lifetime could be, you know, later on you could either, you know, it would expire or you could actually revoke access. So, if you imagine, excuse me, you imagine handing over your credentials, you'd have to go in and change your password in order to revoke access with an access token. You can simply invalidate that access token. Now, a part of what made this all work was user consent. And so, a part of this might be, you know, it depends on whether you have a customer identity or a workforce identity situation, where the client application, in this case, Promo's UI red, is making a request in this example, the scope is to read promotions. And the organization that owns the resource, that owns the resource server, is represented by that little ice cream cone icon. This is an important part of OAuth, where the user then indicates that they want to allow or deny access for the client application. You don't have to do this, by the way. This is only really applicable to, you know, more public situations, more customer identity situations, where you have two different parties that are communicating, in my example, Meetup and Google. If you were just in an enterprise situation, you would not need to do the consent step. The OAuth actors, I talked about this previously. The OAuth actors, the user who's involved here, we refer to them as the resource owner. In this case, Meetup is the client application. Google is the authorization server, and Google Calendar was the resource server. Meetup wants to access those APIs over at Google Calendar in order to perform that automation. Google is going to grant that access in the form of access tokens, and Google Calendar is the one that has the APIs that provide that automation. If we map this again, so here's our resource owner delegating access to the client application, the client application requests the access tokens from the authorization server, and the client app then uses those access tokens to access resources over there on the resource server. All right, I'm going to do a quick little quiz, and so this is something you can just follow along at, you know, do on your own. Should I use OAuth? Do you think this would be a good sort of situation to use OAuth? So let's go through the first one. You have a service oriented architecture service, so let's say it's using the SOAP protocol. In this case, would it be a good use case? Probably not. So OAuth, you know, you probably wouldn't want to try and, you know, essentially, let me just say this, SOAP has its own mechanisms, so there's an envelope and there's a, you know, a header and a body and all that kind of stuff. So SOAP would not be a, you know, a good use case for, you know, for OAuth. What about an API gateway project? So maybe you have something from Apogee, Kong or some other system. This would be a great use case for applying OAuth to secure your APIs. Those API gateways support OAuth as a mechanism for securing access, and so anytime you have an API gateway, that's a good use case for applying OAuth and API access. For an internal REST API, or actually it doesn't even have to necessarily be internal, so a REST API is also a great use case or a great target for applying OAuth. And then finally, an EJB, so for those of you who are as old as me, remote method invocation, RMI, so in this case, it has its own mechanisms, once again, not a good use case for applying OAuth. So really much more modern types of architectures. Now the resource owner, I talked about this previously when we talked about consent. When, you know, when you think about the public internet, the resource owner and a customer identity situation is the end user. If you think about your personal data, you think about your financial data, it's your responsibility to guard that and to protect it. And so consent is given by you, the end user, as a part of that request for access. Now in workforce identity, it's a little bit different, and typically the consent is being supplied by the administrator. So if we take an example, let's take salesforce.com. Even if I create the data in salesforce.com, so I go in, I'm a sales rep, I'm creating, you know, account records, opportunity records, all that type of CRM data, I don't necessarily own that data. And so when an organization thinks about who should get access to that data, it's not based on what the, you know, the worker wants, it's based on what the security administrator decides in terms of who gets access to what. And so we can map that resource owner, you know, type of responsibility when it comes to consent to that security administrator. Now when we think about API access within Okta, and you know, how does this all work? So over there on the left-hand side, Okta is the authorization server, and Okta has access policies. And the purpose of the access policies are to decide if you issue a token for an application. And then how long is that token going to be valid for? The client applications are going to request those tokens from Okta, the authorization server. Then they're going to use those tokens in order to access the resources. So over there on the right-hand side, we have A, B, and C are different APIs which are protected, you know, with OAuth. And so we're going to need to present those access tokens in order to access those endpoints. Now in Okta, it's a little bit complicated. And the reason is, is that for a given Okta org, you will see, or it has the multiple authorization servers. So your Okta org is essentially not just one authorization server, but multiples, okay? Now we have terminology for these. There's the org or the base authorization server. This one is for single sign-on. So when you think about doing single sign-on with OpenID Connect, this authorization server, which can be found at your unique domain, yourcompany.okta.com slash OAuth2 slash V1, this one's all about requesting ID tokens for the purpose of doing federated authentication, in other words single sign-on. Now Okta also has another authorization server that we provide to our customers who have bought single sign-on. And that one's called the default authorization server. The way I want you to think of this one is think of it as a, you get the first one free. So for people who have not purchased API access management, you can try it out in any of your orgs using the default authorization server. Notice the URL is slightly different. It's OAuth2 slash default slash V1. You get one of these and what you can do is you can try out with one of your APIs using API access, even though you haven't purchased that product. The custom authorization servers is for our customers who have API access management, the product. And now they want to do a high degree of customization to really get this thing to do what they want it to do. So in this case, what happens is you define a custom authorization server for each resource server that you want your client applications to access. You can define as many of these as you want. And essentially what we do is we generate a unique ID for each of these authorization servers. Now let's now talk about access tokens. An access token is a implementation of a JSON web token. And so the idea here is that a JSON web token is a couple of JSON objects with a bunch of key value pairs. And these are called claims. And in these claims, we have identity information and access information that's relevant to these requests. So let me walk you through it. ISS is a claim that stands for the issuer. So this is the URI of the specific authorization server in your octa org that generated this token. AUD stands for audience. This is the intended recipient of the access token. So in our case, it's the resource server, typically what people do is they use the URI of the server. But it can just be any string identifier that you create. It does not have to be in that format. There is an expiration. This identifies when the token will expire. Very important. You don't want to accept a token that is expired. The CID is the identifier for the client application. So in this case, CID, when you generate an application in octa that is of type, open ID connect or OAuth, octa will generate a unique client ID associated with that. And what you would do is you can then verify that client ID in the access token to identify what client application is this token intended to be used with. There's UID, which is user ID. This is the user associated with this request. And then scp stands for scopes. These are the permissions contained within this token. So I talked about this previously when we talked about the meetup example. Remember I said that the token that was issued to meetup had the ability to perform write operations, but it did not have the ability to perform read operations. So in this case, this token has the ability to both read and create promos, but maybe it's missing the permission, let's say, to delete promos. It does not have that capability. And then the subject is the who. You'll notice that it's matching the UID up above. And the reason is that in this case, this is a part of a user oriented grant within OAuth. You do have the capability to do system to system that does not involve a user in which case the UID would not match the subject. In that case, the sub would be equal to the application ID, the client ID. So for those of you who have attended the previous session I did on OpenIDConnect, we had our ID tokens that we were working with for the purpose of single sign-on. They also had an audience and an issuer and a subject. Now the key differences that you'll notice here is that when you're talking about an ID token, notice that the audience for the ID token is the application, the client application, so the relying party's client ID. As opposed to an access token, the audience for that is the resource server, so the intended recipient. The thing that we're accessing is the API, not the app. The issuer is the same. At the end of the day, this is being issued by an authorization server configured Octa. The subject is in an ID token as the end user's client ID. In the case of the subject, it's basically the same in an access token. And then there's an additional parameter, which is the CID that stands for the client ID of the client app. Essentially, you can think of this, the audience in the ID token would match the CID claim in the access token. Those would be the same values. All right, so let's do a quick little quiz here, test your knowledge. So who's the actor? So taking a look here, we have our resource owner, A, B, C, or D. What do you think best defines the resource owner? All right, the resource owner wants an app to do something for him or her. What about the resource server? What best defines the resource server? B, C, or D? So the resource server has APIs that will be accessed on behalf of that resource owner. The client application, so B or D, the client application accesses the APIs on the resource server on behalf of a user, which means the authorization server is going to grant access in the form of tokens. All right, a big thing you need to think about when you think about working with API access management and custom authorization servers is how are we going to approach configuring and setting these up? So I mentioned that in a given octa org that uses API access management, you can have multiple custom authorization servers. Well, how and why would you configure these? Custom authorization servers mean that you can have a custom audience. You can define custom scopes and custom claim data that go in your ID tokens and your access tokens. They support five different ways for obtaining tokens. We refer to these as grants or flows. And so just to quickly run through them, the authorization code flow, the authorization code flow with Pixie, the implicit flow, the password flow, and then the client credentials flow. So think of this as, for different application architectures, different mechanisms to obtain the tokens. So different mechanisms that the client app uses to obtain the tokens from the authorization server. And then finally, a custom authorization server gives you the ability to configure what are called access policies. And that determines your rules, your security rules, about when and if you will generate a token, issue a token, for this request. All right. So how many custom authorization servers would you create? What you want to do is you want to identify resource servers as a logical collection of related APIs. We'll look at an example, but it's not necessarily something like for every host. I create a resource server. It's not about where the app lives. It's a logical set of APIs. However you group those APIs, you would consider those to be a resource server. What you're going to do is associated with each of these logical collections of APIs, you're going to define an associated authorization server. Notice it has a unique audience which identifies that resource server. And then a set of custom scopes, which are permissions and custom claims, which are pieces of data that would be in the access tokens that are being sent to the resource server when we request whatever that service is. So let me give you an example. In this case, we have an example in which the organization that's setting up API access management has a bunch of order management APIs and a bunch of sales quoting APIs. So they've created their own set of REST APIs for these two purposes. What they might do then is by identifying these two collections of API endpoints as resource servers, they would define a custom authorize one custom authorization server for each of these. The first one is called orders. The second one is called quotes. The value that they would enter in for the audience, it doesn't need to be a URI, but that's what we're doing. It is the recommended naming convention for a format for the audience. So HPS orders and HPS quotes. And then we're going to define custom scopes and custom claims associated with each of these resource servers. Under the custom scopes, we have orders, read, create, update, and delete. So the classic CRUD operations, create, read, update, delete. We also have a special permission, orders admin for administrative types of operations. And then there's one that's very specific to orders, orders expedite. So let's say that we have a customer who maybe, I don't know, they're down, they need a part as quickly as possible, something along those lines. And so this is a special permission that's maybe only given out to vice presidents or directors or whoever where they can say, all right, this order needs to be expedited. And so they could be granted this scope. And they would have that permission when they perform that API call. Over on the quoting side, once again, we have CRUD, create, read, update, and delete. We also have a special admin scope. And then notice we have one called quotes discount. Once again, very business oriented. So let's say only a VP can approve of a deep discount. So in this case, we could use that as a part of our customs codes. In addition, we could set up custom claims. Now, the key thing here is that here we have things like a manager ID, admin roles, and so on. The thing to keep in mind is that this should be related to authorization logic. Cost center is probably not the best thing to include in here. It really should be oriented towards things like permissions or additional role kind of information that is used as a part of the, maybe the visibility. So if I do a query, I would say I have read permission. I don't necessarily have the ability to read all orders or quotes. Maybe there's something that finds that more on a row level basis. Now that I've defined the authorization servers, I also need to define what are called access policies for each of these authorization servers. So in this case, let's say that I have one of my authorization servers, I'm going to define two access policies. Now the way that access policies work is that access policies are associated with one, many, or all of your client applications. So in this case, what we've done is we've created two access policies. One for internal apps, it's going to have its own set of rules. And another one for external apps that, let's say, our customers and partners use. So in this case, let's once again map this to our real role use case. So in this case, we're talking about our order management set of applications. So the client applications, let's say we have a sales opportunity converter. So the sales rep has gone out, they've closed the deal, and now they're going to convert the opportunity into an order. So there's our front office order application. And then on the back office, the manufacturing order management application, in this case, people actually fulfill the order, this is the app that they use for that. And then in our external apps, maybe we have another app called the customer order viewer app. And this application is used by customers and partners to track their orders. Now associated with each of these access policies, one for internal and the other for external, you're going to create what are called access rules associated with them. Now before I do that and talk about access rules, I just want to talk about how we would model this. So if we have our two client apps and our two resource servers, what you'd end up doing is because you have two resource servers, you would, because you have two resource servers, you would define two custom authorization servers associated with those collections of APIs. Now because resource server A is being accessed by two applications, that means you may or may not, you could have one access policy, but you might also have two access policies. So notice we have an access policy for client app one and an access policy for client app two. In the case of the resource server B, in this case, there's only one access policy because there's only one client app that's accessing it. So going back to here, you've created the access policies according to the client apps accessing your APIs. Now what we're going to do is we're going to define access rules, which determine if you issue a token and how long that token will last. Access rules, as I said, determine if we generate the token and it's lifetime, how long it's going to last. This is based on three pieces of information. What flow are you using to obtain the token? Who are you based on group membership or explicitly referencing you directly as a user? And what scopes are you requesting, which really determine what do you ultimately want to do with the access token? What Octa does is Octa evaluates the rules in the order they're listed. So in this case, what we do is we have a customer rule, an employee rule, and a manager rule. What we would do is we would first evaluate the customer rule. In this case, this one is only giving read permissions for those orders. It doesn't matter who you are when you request it. And in this case, we're using the implicit flow. We will generate a token that will last one full day. Now, let's say that we request not only the ability to read orders, but the ability to create orders. In this case, what's going to happen with the employee rule, or let me actually backtrack, the customer rule will not apply. By requesting both read and create, it's going to say, all right, this is beyond my allowed scopes. So Octa is going to move on to the second rule and evaluate that. In the employee rule, you could request read, create, update, and delete. You must be a member of the factory group. So in this case, there's some group in Octa. In fact, it could be sourced from another location, so AD or an LDAP directory. And then with the flows, it doesn't matter what flow you use, but because this token has additional scopes, the timeout for the token is only two hours. Now, let's say you're that vice president. You have the ability to expedite orders. In this case, if you request the order's expedite scope, neither the customer rule nor the employee rule will apply. You must meet or be a subset of all of the conditions in the rule. So by requesting the expedite, that would take us to rule number three. The user must be a member of the manager group. In this case, the strongest flow you can use from a security standpoint is the authorization code flow. And then the timeout for the token will be very short-lived, only 20 minutes. Now, if you make a request that doesn't meet any of these rules, that means the token request is denied. Octa will block the request that's coming in. It's outside of the scope, essentially, of your policies and rules. So if we go back to our modeling of the Octa entities to the OAuth entities, so what we would do is we define a custom authorization server for each of our resource servers. And access policy is associated with the different client apps that are accessing us. And then for each access policy, we would create one or many rules that decide if we're going to generate or issue a token and for how long that token will last. A very important part of OAuth and security is validating the access tokens. There's really the first four here are the ones that must be done. You've got to validate the digital signature. Octa provides a keys endpoint to validate the digital signature using a public key and standard algorithms. You need to validate that the issuer of the token is your Octa org and specifically that custom authorization server that you defined. You need to verify that the audience matches your identifier for your resource server and that the token is not yet expired. Optionally, you can also check the client ID to make sure that you're only being accessed by certain clients. All right. I'm going to do another quiz. Once again, let's apply what we just learned. So we have our OAuth actor on the left-hand side and the access token claim. So when you think about the authorization server, what claim in the access token represents the authorization server? Is it A, B, C or D? So think about this one a little bit and then make your best guess. All right. So the correct answer here is C, the issuer. The authorization server issues the tokens. So the client application, A, B or D, the client application is represented by CID, the client ID. The resource server is represented by B or D. The resource server is represented by the AUD. In other words, the resource server, the APIs are the audience of the token, the intended recipient of the token, which means the resource owner is represented by a sub, a subject that's basically the who is a part of this request. All right. What I'm going to do is at this point, I'm going to do a demo of the hands-on labs. Now, you're going to get a chance to do this on your own, okay? So we're going to give you the opportunity to access a virtual machine. We're going to give you the opportunity to access an octa.org. There's essentially a set of credentials. If you want, you can go out to this octaes.com, secure API lab guide and download this right now. But I'm going to first do a demo. So I'd like you to watch what we're going to be doing and just think about it. And then after you've watched me and you've thought about it, then you're going to change your brain mode and you're going to get to apply and do what we've been talking about on your own, okay? All right. So let me do this. Let me jump out of here and let me go into my virtual machine. When you go to that URL, we'll be posting it later. Just so you know, don't worry about it. We'll put it in the chat window. You're going to be able to download a set of lab instructions in order to do these hands-on labs. Sorry, let me scroll down here. So the first thing that I'm going to do is I'm going to navigate out to my virtual machine at octa.instructorled.training. Now, later on when we do the labs, each of you will be assigned a unique access code. And so I'm going to use my unique assigned access code. And what I'm going to do is go in here. Now, I already went in here. It's going to prompt you to enter in your name and just enter in your name. And then also you're going to need to click to consent to the policy. It's also going to offer you the opportunity to protect your VM with a password. No need to do that. So if it challenges you to create a password or one it does, don't do that. I'm going to go in here. By default, we're logging in as rtabin. I'm going to go in here and select other user. Once again, this is all in the instructions. And I'm going to log in as administrator and then train me 4321. This is in the instructions. Admin, administrator, not that. All right, administrator. And so, like I said, train me 4321. The password is in the instructions. All right. Now that I'm in or almost in, the next thing that we're going to do is we're going to go out here. Just takes a while to render. There we go. All right. We're going to have you create a directory. So I'm going to go out here, go to the root directory, mkdir, files. And once I've done that, I'm now going to download the files that I need in order to do these, it's basically the starter code to do these labs. All right. The location that we're going to send you when we do this is going to be, you basically have a octaeducationservices.com slash. And then we're going to go to dev lab code. And so this is going to give me access to a zip file. I'm simply going to go to the upper right hand corner, click on the download icon, download this to my downloads folder. So here under downloads, I'm going to take this devday.zip file. I'm going to extract it. So let's see here. There it all, extract all. And what I'm going to do is go in here and select the C drive and then the class files folder that I just created. All right. So now that I've done that, let me see if this, all right. Unfortunately, we have a little issue here, which is the devday creates a devday folder based on the name of the file. Let me just do this. I get, you don't really need to do this. There's probably, I'm probably doing something wrong the way I'm extracting these, but anyways, I'm going to move these up here in order to put them in the top folder. All right. So now that I've done that, I'm going to log into my octa.org. So back here, I'm going to go to octane218000.octapreview.com, training 4321. All right. I'm going to log into this org. This is the first time I'm doing this, so it's going to prompt me for, a lot of you have probably done this before, forgot password question, security image. I'm going to click on create my account. And here we go. All right. So now that I've done that, the next thing that I'm going to do is I'm going to go in and define my application. Okay. So in octa, here under applications, I click on applications. I'm going to add a new application, but I'm not going to use the octa integration network. This is a custom application. So I'm going to create, click create new app. In our case, it's a single page app. So I'm going to select spa and then click create. The name of this application is going to be the promos app. I'm going to add a redirect URI, HTTP localhost 080 slash token callback, like so. All right. This is essentially a URL in the client application that's going to receive something called a temporary authorization code that is then used to request the access token. I'm now going to click on save. And what I'm going to do is octa is going to generate a client ID for me. Here is the generated client ID, the identifier for my client application. Promos app client ID, paste that in like so. Okay. All right. There's another thing we need to do. We need to set up something called a trusted origin. It's here under security and API. And so what I'm going to do is I'm going to create a trusted origin. And what this does, by adding this trusted origin, I'm going to enable something called cores cross origin resource sharing. What this does is it allows an application that is being or I should say a web page that's being delivered from the domain localhost 8080. It allows web pages delivered from this domain to do an Ajax call to my octa org. So this is essentially an allow list. It's a grant list that allows this domain to do Ajax calls to my octa org. By default, browsers block that. It's called the same origin policy. And so by configuring this, we create an exception to that rule. And so when we use the office DK for JavaScript to do this API, these set of API calls, this will allow those calls to go through. All right. The next thing I'm going to do is I'm going to define a custom authorization server since I'm right here under API. So I'm going to click on authorization servers. Now in our example, we're going to be working with the promos API. All right. And so I'm going to go in. First of all, here's the default authorization server. We're not going to use that one. I'm going to define my own custom authorization server. And it's called the promos API on server. Okay. Our promos were an ice cream company. At least we were pretend one. And so we create coupons called promotions. And so we have a set of APIs around those coupons. Our audience in my case, we're going to be running our resource server on port 5000. And then the description protects the promos rest API. I have a problem with my capitals, but that's okay. All right. Now what oct is going to do is oct is going to generate a unique ID for this authorization server. All right. So there's another piece of information that I need to collect here, which is the issuer URI. So I'm going to copy this value. And I'm going to go back into here and indicate that this is the issuer URI. Paste that in. Because later on, I'm going to use that when I'm configuring my resource server. Also actually my client app too. They both need to know about this destination. All right. So this is the identifier for my resource server. And this is the identifier for my authorization server. All right. Now what I'm going to do is I'm going to go in and define some custom scopes. So key thing here is that we need to create custom scopes because we have our own proprietary APIs that do our own unique things. So I'm going to click on create scope. And the first one I'm going to do is the name of this will be promos read. And, uh, oh, you know, I'm doing that award. That's okay. Read. Yeah. That's second uppercase character. All right. The display phrase is essentially used in the consent screen. So this should be something that is understandable to your end users, the people using this application. And the description is additional information to further describe what this, you know, what this permission is granting. So I'm going to click on create. Uh, you can also say this requires consent. Uh, default scope means don't have to request it, but we'll return it and then include in public metadata is, uh, there's a discovery document out there in JSON, which describes the capabilities. Do we want to publish this publicly? So I'm going to create that one and then create a second one called promos create promos. And so this one is create new promos via API. And once again, we'll leave the rest of these unchecked. There we go. All right. So you definitely want to have well thought out, well thought out display names and descriptions for what your APIs are going to do. Uh, under claims, we're not going to do this, but you could define, uh, additional data that goes into your access tokens for that matter, your ID tokens too. It can be one of two types. Let me just click on add claim just so you understand. Within here, you can add it to either the access token or the open ID connect ID token. And you can reference using Octa's expression language. You can reference things on the Octa user profile or the application user profile. And so imagine we might create something called DEP and it would reference, let's say the department attribute on the Octa profile for the whoever the current user is. Okay. In addition, uh, to the user profile, we also have references to groups. And so this would be include the groups that the current user is a member of in the, uh, basically in the, uh, uh, token. All right, we're not going to do that though. I'm going to move on now to the access policies. So I'm going to define an access policy here. When you define an access policy, you're going to give it a name, promos app policy, and then the description. So in this case, this access policy is specific to the promos app. So you can imagine you have multiple, uh, different applications accessing your APIs. You might create policies for each application. So I'm now going to click on create policy. And then I'm going to define an, uh, a rule that you can have multiple rules in your access policies. So much like we saw with customers, employees and managers back on our slides. So I'm going to add a rule and this one is going to be called the read only promos API. And what I'm going to do is I'm going to limit this to just working with the authorization code flow. In our case, the authorization code flow with pixie. And I'm going to say when you could, you could, you could say, I want to apply logic that the user must be a member of a group or a specific user. And then, uh, you can also say, I'm not going to actually do that. I'm going to go in here and say, all right, and then the scope's being requested. So I'm going to do, uh, open ID, which is for the ID token. This really doesn't apply to OAuth email. Once again, for the ID token profile for the ID token again. And now here's the key part. I'm going to enter in promos read. So in this case, when they, uh, request the ability to read perform read operations on our promos API, uh, that's going to make this rule apply. All right. Uh, I'm now going to go down here. Let me just show you the fact that you can define the lifetime of the token. So I could go down here and say, you know what, I want this to last for 45 minutes, something along those lines. So you can modify this to be something, uh, you know, that, uh, in general, the more, the more the permissions of the token, the shorter you want the time out to be. Okay. I'm going to click on create rule. And now, uh, I need to update my application to request the token and then to, uh, use it and also to protect my resource server. All right. So I'm going to go back here to my command prompt window and I'm going to go into class files and go to the day and then promos. And we're going to go to the spa API client, not the promo spa, this promo spa API client. Make sure you go to that folder. I'm going to do an npm install to install all the necessary dependent libraries. Now, uh, as the instructions say, we're going to have you move on to the next lab. This is going to take a while. So to save time, we're just going to start working on the resource server to open up a new command prompt. What you do is you right click on the existing command prompt, select command prompt. And then what you do is we're now going to do this. We're going to go to class files again, dev day, and then the promos resource server folder this time. And once again, I'm going to do an npm install and install all the necessary libraries. This one should not take nearly as long as the client application. So what we'll do is we'll just let this run. Cool. Now what I'm going to do is, uh, we're going to use Octa's JWT verifier. So it is a library for JavaScript. We have ones for additional languages. And what this is used is to perform those checks, check the digital signature, the issuer, the audience, and the expiration to validate that the token is a valid token. And then also it hasn't expired. All right. So I'm going to do an npm install and then do at octa slash JWT hyphen verifier, like so. And then we're going to use 2.0.1 and hyphen save. All right. This one will not take long at all. All right. Now, uh, I'm going to launch Adam. And what I'm going to do is just, uh, walk you through the code. So walk you through the, well, working with the client app and the resource server. So I'm going to go in here to add a project folder. And what I'm going to do is go to class files, select dev day, and then click on the select folder button. Now there's, uh, the two folders that we're going to be working on are the promos resource server and the promos, uh, spa API client. Now in the promos resource server, I just want to point out that there's two key files in here. The setup controller, what this one is, is this one is the, essentially the API endpoints that can be called. So this is using Node.js. And so down here we have, for instance, this will be get called on a get. Uh, if we keep going down, there's another get. This one is essentially a create operation associated with an HP post. There's also a delete down there for an HP delete operation. Uh, and so these are the different endpoints that we can call. And what we're going to do later on is we're going to update this to require the, uh, the tokens. Over in the security utils, the purpose of this one is to have the logic, which uses the JWT verifier, um, to then check the authenticity of the data in the access token that's being passed. All right. So in the security utils, the first thing we're going to do is we have a reference to the, uh, class associated with the JWT verifier. One of the things you can do to toggle comments on or off is just do a control forward slash. Uh, the next thing I'm going to do is on line nine, I'm going to update the audience. So this needs to match. I'm going to enter in the audience value local host port 5000. Okay. Uh, the key thing that this needs to match if we go back to here, go back to my authorization server. There's the audience, right? That must match. And so that's what I'm doing there. Okay. All right. Uh, we're also going to uncomment lines 17 through 24. Let me uncomment those. Uh, this is going to instantiate the JWT verifier and we're setting up a bunch of properties such as the issuer URI. All right. So what I'm going to do is I'm going to go back to my notepad and I'm going to copy the issuer URI, do a control C and then go in and do a control V right here. Like so. All right. The client ID, uh, is something that we're going to pull from a command line, uh, environment variable. And then later on, uh, once we have, so the audience was declared up here, we're also going to be working with the scopes on a case by case basis on an individual endpoint basis. Uh, the other thing that we're going to do is we're going to make available by uncommenting lines 27 through 35. This is the function that we'll call when the API endpoint is, uh, called in order to validate the access token that was passed. All right. So now what I'm going to do is I'm going to click on save. And now I'm going to go back to the setup controller and I'm going to turn on security for the, uh, promos read endpoint. So right here, I have a, uh, essentially, uh, this, uh, function call over to the, the, um, uh, check that the access token being passed is valid. And also this is the key thing is being presented or has present the promos read scope. All right. So this is, uh, our rest endpoint for getting promos. And in order to get promos, you must have the scope promos read in the access token as a part of the request. Okay. All right. All right. Um, all right. So now that I've done that, let me just save the file. And then what I'm going to do is start the resource server. So I'm going to go back here to my, basically my windows. Uh, this is the one that has resource server. So make sure that you go to the, the one that has the current directory set to resource server, not the, the single page out. I'm going to set the octa client ID, oops, ID equal to, and this is where I'm going to go back in a notepad. And I'm going to grab the client ID and what I'm going to do is I'm going to paste that value in like so. So I'm going to set up that environment variable and then what I'm going to do and then start. Yes. And there we go. I'm going to start up, uh, start up node and now my API server is going to be available and callable. Okay. All right. That's all done. So now I'm going to move on to the next part of this, which is to update the client application to request the tokens and then to add them to the outbound request. All right. So over here, back in Adam, I'm going to collapse the resource server folder and now focus on the, the spa API client. Let me actually close down these windows here. All right. Uh, in here, we're going to have you navigate to the off folder in the index.js. This is going to need to get updated right here where it says your org URL. In my case, I'm 218. It's nice and easy for me. I'm 0, 0, 0. For the authorization server URL, this is how we find your, you, this custom authorization server that we defined. I'm going to go in here and this is where it gets a little bit tricky. I need to copy the ID of the resource server right there. So I'm going to copy the ID of the resource server. It starts with AUS, logically, right? And so I'm going to update that so I have my unique authorization server ID. Okay. All right. I'm going to now save the file. Okay. And then I'm going to go into my first window, which is where I have the single page app. Once again, I'm going to do set octa client ID equal to and what I'm going to do is I'm going to paste in this value like so and set that environment variable. And then I'm going to do an mtm start, start up the web server. All right. When I test this, I just want to point out that when I test this, it's not going to work. And the reason it should fail is that I'm not requesting the proper scope. I'm not requesting promo's read. And then the second thing that's going wrong is not only am I not requesting the proper scope, down at the very bottom, we have this get off header function, which right now isn't doing anything. We're going to need to make sure that we add the access token that we get from octa to the outbound authorization header when we do our request over to our resource server. All right. So this is going to fail, but that's okay. All right. So what I'm going to do is I'm going to go over here into the Chrome dev tools and take a look at what happens when I run this. All right. So now that I have this open, I'm going to go here to my profile. Now, I'm already logged into octa, so it's not going to prompt me to authenticate again. I'm going to go in here and click on my profile. Let's see here. What did I do wrong? Authorize client ID, code challenge get. Let's see here. All right. I'm going to do a little debugging. What did I do wrong? Code challenge. Pretty sure my octane 218. Yes, 218. OctaPrivy.com. My ID looks good. Client ID. Oh, wait a minute. All right. I see what I did. All right. So here's my problem. My client ID in my memory or in the clipboard buffer, I basically had my authorization server ID, not my client ID. So I took, I needed to select this one. All right. So this is a fix I can solve. All right. So I'm going to go to a control C. And what I'm going to do is let's try this again. Set. Yep. There's the problem. All right. It starts with AUS. It should not start with AUS. So I'm going to go in here, copy this. All right. Let's try this again. Well, there's always fun little things you run into. And that's why, that's why prefixes are quite useful. You can debug. All right. So let me try this again. This will actually, yeah, it'll launch a window automatically. So now when I try this again, I'm going to click on premium promos. What's going to happen? Let's see here. I think something else bad happened. Oh, all right. Boy. Right now is the, if it could go wrong, it will go wrong. All right. So let's just take a look here. It says, user is not assigned to the client application. So what I did wrong is over here under applications. When I go into my promos app right here, the thing that I skipped over was I did not assign the application to my current user. So I'm going to go in here, click on assign to groups. Select my everyone group, click on done. There we go. All right. All right. So now, all right. Now that we've done that, let's try this again. All right. So third time's a charm, right? So I'm going to click on premium promos. Oh, awesome. I got a token. All right. So here's what we're going to do. So just so you know, I got a token. So here's my access token. All right. Now, the access token has a problem. First of all, when I do the request, I don't have the proper scope, and I haven't added it to my outbound header. So let me just go back to premium promos and show you what happens. So when I click on get our premium promos, what happens is that I get an HP 401 response from the server. And the reason is, once again, is I don't, in the outbound request, I do not have the authorization header populated. In addition, I need to update this to request the promos reads go. So two things wrong right now. All right. All right. So what I'm going to do is I'm going to return to Adam, and I'm going to go in here, and I'm first going to make this change right here. So I'm going to say I also want promos read. I also want the promos read scope. All right. Down here under the auth header or get auth header function. So that's a bad idea. All right, there we go. Down here, I'm going to get the token using a little helper function up above. Let's just do that. And then we're going to add it to the outbound header. So remember, by the way, this is header is not header. I had a nickel for every time. This didn't work because someone did header authorization. So we're going to add it to the authorization header. It is a bearer token. Oops. Always make sure you do this space. That's another one. And then we're just going to take the raw access token and add it to the outbound header. Okay. All right. So now that I've done that, what this does essentially, let me just kind of show you, from the page that calls that basically does the request to get the promos, what it does is it says, all right, let's go add the access token to the authorization header. And then what we'll do is this gets called and then we add the access token to that authorization header right there. All right. All right. So now that I've done that, here's what I'm going to do is I'm going to go back here. And I'm going to, here's the thing, I need to delete the previous token. The reason I need to delete the previous token is it doesn't have the proper scope. All right. So taking a look here. Open ID, email and profile. In fact, why don't I just do this? So I'm getting back a 401. I'm still getting back a 401. All right. Because I don't have the promos read scope. Okay. So you could either click log out, which is what we do in the instructions. Let's do this. I'm just going to go in here and say delete this. So delete all my octa session storage. And now I'm going to request, basically request new tokens. All right. So let's take a look at the new token that I got. Email, open ID, promos read. All right. Now we have the necessary scope. So now when I go in here to promos read and click get our premium promos, my call succeeds. And if you want, you can check that out on the network request. Okay. You can go check out actually the resource server, the resource server basically got the valid request and returns the JSON response. All right. Okay. This means that we have an hour over an hour to work on the labs. So what we're going to do is because we have not that many people here who a lot of people signed up and then they didn't show up. We were, we sent this out to 125 people and looks like we have roughly, you know, I don't know. Looks like 25 people. No problem. So what we're going to do is we're going to jump into our labs. Let me just finish up my presentation. All right. So at this point. All right. What we're going to have you do is we're going to have you go to this URL. I'm Precky and I am here with Brian Demers. And we are here to do, or Brian's here, rather to do, to give you a demo and introduce yourself. All right. So I'm Brian Demers. I work with Aaron on Octa's evangelism team or advocacy team. Sorry. I said, my brain still, still trips on that every once in a while. But yeah. So I've been working, I don't know, on and off of the past year or so on this tool called the Octa CLI with the express goal of making developers getting started with Octa easier. So we talk about this a lot on our blog. You know, we write a lot of posts about how to use OAuth with X, right? Like I'm a Java guy, you know, by, by sort of history, I guess. So, you know, how to, how to integrate spring with, you know, Octa, right? It's all OAuth under the cover, it's all standards, which is great. And we do a lot of those types of posts, right? So your front ends or back ends, whatever you want. But they're all sort of the same when you get down to it, right? You go to Octa, you configure some stuff, and then you take those configuration bits and you put them in your application. And every IDP works like this, right? So if you, if you configure social OAuth with Google, it works the same way, you have to go to Google's dashboard and find the bits you need somewhere, you know, following some blog posts or documentation or whatever it is, and then put them in your application. And it's a little bit of a dance. So our goal with this tool was originally just to make that process easier. And it's sort of starting to grow and to be a little more than that, which is, which is awesome. But yeah, so, so I'm going to get started here. So the first thing, I should say the first thing, history, what history, here's some background I'm going to do, if you followed the first, the first lab session of the day, we built a little view application. And that, that whole process, I don't know, took people, once they got to the start with the lab, took any people from half an hour to an hour. And I'm going to try to do that in a couple of minutes. I'm going to drag the process out, because, you know, we're on this video. And, you know, I don't, I don't want you to blink and miss it either. So, so I'm going to try to drag it out and install everything. And then we're going to end up with a very similar app view, a few front end app that you would have had this morning, if you followed along. So the first thing I'm going to do is I'm going to share my screen. And then oh, come on, share screen. If I can remember how to do this. Here we go. All right. So I'm going to go to cli.octa.com. And we're actually improving this site. So so don't worry about that too much. And we're actually embedding some of these directions in our new upcoming blog post. And I know Matt Rabel, who was on the feed earlier, has definitely been doing a ton of work to update a lot of our blog posts with this information as well. But at the end of the day, if you're on a Mac, you use brew. If you're on Windows, you can use chocolatey. And if you're on Linux, you can use flat pack or both Linux and Mac also have a shell script option. But basically, you're going to get a binary, you're going to put it on your machine, and you're going to run it. Right. But that that's what these tools do. So if I've successfully uninstalled things to pretend I have a clean machine, this will work. So I'm going to grab, I'm going to grab that URL, or not the URL, the command, brew install, which is just installing this cask. And that'll take, you know, a few seconds. Hopefully. There we go. All right, so that's going to install the latest octa CLI. And it's going to link set up my path and do all that stuff for me. And then just to make sure everything's working. You can run the good old version command. Right. So everything, everything's good. It's installed. Pretty, pretty painless. If you already have an octa org, then you can you can run octa log in. Okay. But if you don't, and you need to go register, the CLI will do that for you automatically. So you can either run octa register, or you can just run octa start, and it will do the registration for you. If you've already logged in, running octa start will just use what, you know, your, your existing, your existing configuration. So, summarize this. Oh, go ahead. I have a question. Sure. So octa register, that means you can actually sign up for an octa developer account from the command line. Is that what it does? I should have led with that, right? Yeah. So I don't have to, yeah, I usually do, but it's a lot of form. Yeah. Yeah. So I usually leave with that, but it's so baked into my head now, just it's automatic thing, right? Because I've done this a hundred times, right? But yeah, so if you run octa register, I'm going to run octa start, but it kicks off the same process. And it will prompt you for an account and it will do all of the registration for you. So, you know, Brian, it's Merz, and I'm actually going to use my personal account here. And then a company, hell yeah, let's just say octa. This, this will take a minute, but this will send me an email with basically a totp code. And just to prove that, you know, I'm a real person. And I'm going to go check my email outside of the screen here. We don't want to see your inbox. You do not want to see my inbox. I do not want to show you my inbox. All right. So I have a totp code. Now I need to find the streaming window again. All right. So I'm just going to paste this as a six digit code. I'm going to paste it in here one time use and hit enter. And that's verified my account. And then I'm actually going to go to this URL first to set the password. Oops, I can't copy from that screen. I'm seeing double on my end. So I apologize. All right. So this is my new octa org. So I've, I've literally set up a brand new account and I'm setting the password for the first time. And you know, make sure you use a strong password here. I bet you I typed this wrong. Use a password manager or something. But for the sake of this demo, keeping it simple, hopefully I can remember I did not type it right. So I knew I wasn't going to do it. So one of the downsides of passwords, right? Oh, seriously. Oh, it's a bad password. Oh, good. That's new to me. Okay. So let's do what was it? I'm not going to tell you. That's bad. Oh, it's terrible better. Yeah, I really should. I was just testing the system. Yep. It's nice, uh, pointing out that little feature we have there. Right. Right. It's really what I was down. Good. Okay. So, so I've logged in. I've just set my password. And I'm going to ignore this dashboard for the rest of this tutorial. Right. But I have an account. This is brand new. You can, this is a, uh, you know, free tier developer account. You can use this just like you were signing up through, you know, developer.octa.com. But jumping back to my terminal here, I'm going to continue. It's just waiting for me. So as I mentioned before, I'm going to create a view application, basically the same thing we would have done this morning in the lab. So I'll click number two. And this is going to download a sample app for me. And it's going to configure it. It's going to configure Octa. So it's going to set up an, um, an OADC application. It's going to create, get my secret. And it's going to configure my application for me all automatically. And I can get into that in a minute where those properties are and how that is. But the idea is, well, it's right here actually. Right. It's written to this property. But we'll get to that in a minute. So continuing with the demo, I'm going to change the directory, go into this new view folder. And then it's an NPM project. So we assume if you're a no developer, um, you have NPM installed, right? Uh, so I can run NPM install. That'll take you an hour and a half. It's quick. Uh, it takes, I don't know, this one takes 20 seconds or so, depending on your internet connection. Hopefully I may have lied to you. NPM install is everybody's favorite step of this process. Yeah. Yeah. I mean, every tool does the same thing. I'm a Java guy. Maven downloads the internet. Um, you know, I, you know, Python does the same thing, right? All of these tools download the world. Okay. So great. So, uh, I've installed a package that means all the dependencies are on my machine. There's no, uh, vulnerabilities in this project, which is even better. We try to keep these up-to-date, uh, as possible. So then the last thing to do is run NPM start. And this, if I've done everything correctly, we'll spin up an application, or spin up the application. And I'm going to create a new incognito window. Hopefully, uh, you can see this one, right? Yep. Let's go back to, to this. This is still building and running. Uh, I'm using an incognito window just, just so, um, you can show, it'll show that, uh, it'll prompt me to log in. If I use the other window, I just logged into my octane dashboard. So it'll look like an SSO type, type of session. So cool. So this thing is all up and running. Let me grab, um, my URL. So it's just localhost 8080. If I go here, so we have this nice little example, um, that uses the pixie flow. And if I click login, we're going to get redirected to octa, do the login dance and come back and all the OAuth stuff, you know, is handled behind the scenes. And Aaron can tell you all about that if you want. So if you have questions, put them, put them below. Let's see if I can remember that password that I just, I just had, I get it right. I did. Great. So, so now I'm logged in. So now I have a couple of other things I can see, right up here. I can see a profile and I can log out. If I click profile, I'm going to see the information that was in my ID token. So this, you know, basically that's it. Right. So I've created, um, I've signed up for new octa account and, you know, that's free. Uh, I've downloaded a sample application, configured it for my new octa org. Um, and now I have a secure view application running in, I mean, I didn't time it, you know, a couple of minutes, right? That was pretty quick, I will say. Yeah. And, um, so, you know, the demo has log out, um, so you can log out and it's, uh, it'll kill the octa session. There's this other little messages tab that's, that's combines with another example. If you have another resource server, that's sort of outside, uh, my demo for today, but. So wait a second. You didn't actually write any code. I did not write any code, not one line. That is correct. So, uh, and if I don't know enough or anything about security, I didn't have to write any at that security code, right? I didn't have to learn about, uh, you know, which OAuth flow is right for me or any of those. I just bootstrapped a new app. No, don't get me wrong. I feel it is important for to understand the security of your application, but I also don't want that to get in the way of me, you know, doing my business logic, right? Right. Well, and it's frustrating when it's kind of the first thing you have to do before you can even get started is figure out this, how to make your application secure. So this is nice that you kind of just get a good starting point. I see that it was using pixie. So it's using this more secure flow by default. And yeah, that's cool. Yeah, absolutely. So, um, we have a handful of examples in the CLI right now. So let me kill this and I will show you the list one more time. And so, so I've already registered for octa accounts. If I run octa start again, it's not going to register for a new account, right? I'm just going to drop it into, you know, pick a, pick a sample. But right now we have you, we have spring, angular, and a couple of reactive examples. We're adding more. And if there's something, you know, anybody wants to see, you know, let us know. And we'll, we'll jump on that actually. But, you know, I'm not a JavaScript guy. So, you know, I normally would pick like one of the Java variants, right? So pick whatever works for you. And the process works the same. You know, at the end of the render running start, it'll just say, you know, go back to your native tools, right? The spring one uses Maven. So it ends up being a Maven command. You know, the dot net one obviously uses the dot net tool chain. So you get a dot net command to run. And, you know, basically, the, the samples all look very similar. And you end up with a, with a functioning app. That's super cool. Looks like we have a, looks like we have a question in chat. Let me pull up the chat here. Josh says, trying to figure out how to install the CLI app in corporate environments where all the prefix are not allowed. So, yeah, that's a tough one. So you can go to, so let's see if I can, this is an incognito window here, but hit hub dot com. Whoops, I can't type can I octa and the repo is octa CLI. And you can hit up the releases and all the binaries, you can grab it from here. So the Mac Linux and Windows binaries are here, you can just extract the, the zip and the, you know, if you're on Linux or, or Mac, the, the, the execute bitch should be set, but it's a zip file. So, you know, your mileage could may vary there. That, yeah, that might work. And Mike is also suggesting building from a source to, which I guess is definitely you can, you can build from source. There's nothing, there's nothing secret in here. So there, there are instructions back on the main page to at least there should be, if I've done my job correctly, right? Hopefully we stuck it in here. Ah, there we go. Yeah, yeah. So the project uses, uses Grawl VM, which is a Java runtime. Those details are probably not important unless you're interested in building the source. And you, but basically install it, run it, and you're done. Cool. That's fantastic. Yeah, this looks like a very, very good way to get started. It's certainly, so you had to go to the website to set the password, but that was the only thing you used the web, the octa website for, right? Was just doing your initial sign up. Yep. Yep. So, so all of the, the, the, you know, the idea here is that we, we want users to stay in their, their comfortable zone, right? So if you're, if you're, if you're not, if you're not comfortable with the terminal, don't use this tool. You, we have a, you know, user interface for you, we have instructions for those users, users too. That's totally cool. But if you're, if you're a command line savvy, and you know, you like the idea of automating the world, then definitely check out this tool. And like I said, if you have an existing account, if you've already signed up, you know, through the wizard, you run octa login and it'll, it'll walk you through how to go set up the CLI for you. Can you show us? I'm actually curious. I can, hopefully. It'll let me, let me, let me kill this. Oh yeah. All right. So we're back on here. Let me move some stuff around so I can show it. Whoops. I'm typing the wrong thing on the wrong window. Bear with me. All right. So I basically, oops, oops, oops. Once again, sorry. Get me off, Aaron. So the configure, right, the configuration is all stored in in an octa directory in your home directory. And this is a lot of our SDKs work like this. It's very similar to like how the AWS tool works and those types of things. So I just moved my, my configure the way. So now if I run octa, octa login, it should prompt me for my octa URL, right, which would be, let me get this out of the way, which should be this URL. Did we show this earlier? There we go. This one right here. So I'm going to copy that and paste that here. Oh, it doesn't have to type HTTPS. That's a good question. Maybe you should solve it. You want to try that? Copy and paste. Yeah, try it without. All right, all right. Code it defensively. All right, we'll see if I'm, I don't think I'm that good. Yeah, so, so it, it does show you how to go find, you know, a decently, decently useful error message, though. So yeah, at least good. We did spend a lot of time on some of these error messages. All right, so let's try that again. With protocol this time. I thought probably should fix that, huh? All right. So now you did API token. So we, we have started updating our, our, all of our APIs to, to allow all tokens. So in the very near future, I hope that this tool will also use that, which you know, at least you can, you can downscope your token or however you want. And, and, but we have a bit of a chicken or egg problem that you need your auto or before you can go set up, you know, a token. So, so it's a, it's a, it's an interesting problem to work out. Right. Anyway, so this is sort of the traditional route of, you know, it's just an API key. So with octa, I can go over here to, what is it? Security, I think it's over here API. There we go. And then tokens. I'm going to create a new one for this demo. And I'm going to have to delete this, of course, right after this call. But yeah, I mean, you're going to delete the whole organ after the call. Yes. Yes. Very much so. Oh, I think he shows it to the screen. Terrible. Oh yeah. All right. But I am all set up now. So now we can run octa apps. And that's just going to list all my applications. So, so we took inspiration from, from the Heroku CLI. So if you're familiar with, with how that works, where we try to, you know, take, take some of the similar ideas, but this should run and list the app that I just created. So now I, I basically started with an existing org. I ran octa login. I typed in my, my URL, my API key, and now I can run other commands. And there's a hidden feature in here too. It's called octa logs. I can see all of, you know, my log activity or whatever. So there's, there's, there's some cool things we're, we're trying to add in here as we go. Yeah, that's awesome. That is super cool. Yeah. So do we have any other questions? Can I answer anything else or What do you think? It looks like Matt wants a shirt that says I heart the octa CLI. I too want a shirt that says I heart the CLI. Yeah. So Matt, you should, you're the t-shirt wizard now, I think. So you should get on that. Oh, Matt wants to know about octa logs. Why did that? Why was that a hidden feature? So I don't know, to be honest. So like, I do know. So it ended up being from a hackathon. So one of one of my colleagues created a hackathon and used, used to go, I think, but I remember right to, to sort of prototype some of these ideas. And he had this logs command. And I wanted to see if it will work. So, so I, I, I quickly added this octa logs feature, but I hit it because it's a little tricky because you're the logs at octa are a little delayed. I think there's up to like two minutes delay. So if you're following your logs and you log in, it's not super obvious. It makes sense from oxygen replication and whatnot, right? But you know, if you're watching this, go ahead and use it. But you know, there's some limitations that I think we just need to document around before. Yeah, it's true. I would expect a CLI log tool to be tailing it in real time. Right, right. So, so that delay is sort of, I got you if you're not ready for it. Yeah, yeah. I mean, it might, it might be seconds, right? But, but it's up to two minutes, I think. Yeah. No, that's fair. Matt, Matt has another question. How do I add new redirect URIs to an app? That is a great question. So if you have an existing app, you cannot yet do that through the CLI, you'd have to go through the octa dashboards to it. I know, I know Matt has been, he would love to see something like, you know, I think, I think, I think ultimately what we want is probably like octa. Oh, yeah, there you go. Thank you. Octa apps config, like your eye or so or redirect URI or something, something like that, I think is our goal. And then, you know, you could add your new one here or set them, you know, it's an array. So it's a little tricky. Do you, do you require somebody to update the whole list? Do you, do you say, you know, am I always a big add? Yeah. Yeah. So, so there's some tricky things we have to work out, nothing, nothing monumental, right? We just need to sit down and think about it for a few minutes. But yeah, fair enough. All right. Well, cool. I think we're about at the end of the time. And that was an awesome demo. That was very straightforward, very pretty easy way to get started. Definitely exciting. And it's going to clean up our blog posts a ton. I know. Yes, yeah, Matt, I know Matt's been working really hard updating a ton of blog posts. So we, you know, for for background, we just updated the admin console and octa. So things are a little different. So, so some of the UI didn't quite match up to a lot of the screenshots we've taken before. So Matt has been going through and updating a ton. So he's been, he's been, you know, doing all the heavy lifting. Yep. Everybody should send Matt nice comments. Absolutely. Absolutely. Yeah. All right. Well, that's, that's it for this. Thank you, Brian. Thanks for joining the stream today. Thanks for having me. Yeah, absolutely. We're taking another short break and come back in a few minutes and we will be back for some more Q&A with Micah and then have one more demo for you before we wrap up for the day. So thanks everybody for joining and we are back. Good to see everybody back here again. Thank you all for joining and back here with Micah again to wrap up the day with a couple of things. We'll be doing random Q&A again. So as always, feel free to drop questions in the chat if you are watching live and Micah will also be showing the Heroku demo. So nice. Yeah. So we kick it off. Why not? Let's do it. All right. So let's see where I go to share my screen. Not that one. This is what happens when I give Micah director power in the stream. There we go. Okay. Is it correct? Yeah, looks good. My Heroku screen. Okay, cool. So just in case you're not familiar with Heroku, it's an application hosting platform. It's very easy to use. It's very robust. And one of the cool things that it has is this notion of add-ons. And if you are familiar with Heroku, you've almost certainly used these. You can go and add say a MySQL add-on. Yeah. I've added like databases and like Redis. Yeah. Postgres, Redis. Oh, here we go. Find more add-ons. That's what I was looking for. Right. So it has all of these and really handy stuff for just about any type of application you'd be deploying. I forgot what I just called this here. Like a general demo. So I can add a free tier of MySQL super easy to this app. And from here, I can switch over to a paid tier if I want and may all have different levels of access. And just by virtue of adding this, in this case MySQL, it also sets a bunch of configuration like this JAWS DV URL is now connected to MySQL instance. So that's generally what add-ons are in Heroku. And we've created an octa add-on that makes it super easy to add octa to a Heroku app. And if you tuned into the previous demo from Brian, this is very similar to what's going on with the octa CLI. And it even shares some elements of the back end. So what I thought I would do here is show you in the context of jhipster, which Matt demoed earlier, jhipster has support built in for deploying to Heroku and for the octa Heroku add-on. So it makes for kind of a full circle demo here. And I previously installed jhipster. And so I'm just going to run this command to create a jhipster app. And it's going to ask me a bunch of questions. I'm going to create a monolith application. I'm going to call this, what would I call the first one, jhip hero demo one. I don't want web flux. So I'll leave the default package name. Now here's where things get interesting. And we're all in this kind of ties together. So jhipster has some sensible defaults. And one of the defaults it's assuming is that you're going to build an app that needs auth. And there's a bunch of different options here. But we can choose awath and oidc. And it works with key cloak and octa out of the box. Key cloak is a very robust, well written kind of on-prem awath server. Octa is a cloud service. And it works with either of those. I'm just going to select some other defaults here. No database, no cache. We'll leave it as maven because everybody knows maven is better than gradle. Thank you, Matt. And I don't need anything from the jhipster registry. We can choose a front end. In case you didn't tune into jhipster earlier, jhipster is an application generator that after you answer some questions leaves you with a fully functioning app with a spot front end and a spring boot back end. And you have a bunch of choices here for the front end. I'm just going to choose react. I don't know react very well, but we'll see at the end of this that I have a fully running ready to go application that's integrated, that's deployed to Heroku and integrated with octa. I'm not going to worry about generating an admin UI. I have some choices for themes here. I don't want internationalization support. I don't need anything extra. And so now it's going to generate this application. Now I'm actually going to let this one run because it doesn't take too long. The next step takes a little bit longer. And so I pre-created a jhipster app with Heroku integrated. So we'll do a little bit of the old style cooking shows in just a moment where I'll take the completed recipe out of the oven while the real one is cooking. This should just take a moment. And this is setting up everything that we need for the front end app, which as Brian talked about earlier involves downloading the entire Internet with many NPM type projects. But this doesn't take that long, about a minute, unless I'm lying. I think we're just about done. Give me back my command line. There we go. All right. So now we have a basic jhipster app that's ready to integrate with an OAuth service of my choice. Now I'm going to set it up so that it's actually going to deploy to octa and use Heroku. And to do that, I just type in jhipster Heroku. Oops. That was not what I meant to do. Here we go. jhipster Heroku. Now it's going to ask me a couple more questions. I'll leave that as it is. I'll deploy to the US region. We'll use Git, Java 11. And here's where I can say yes, provision the octa add-on. So this is where it's going to not only deploy this application to Heroku, but it's going to provision octa along the way. And similar to what Brian was showing, we're going to see that there's no need to interact with the octa admin. This is all command line stuff. Is there a question? This is doing a bunch of things at once. This is up until this point, you've now got a running application that you could run on your machine, right? Right. But next step is to deploy it. And you're going to both push it to Heroku and make an octa account at the same time. That's right. So there's a lot going on. And maybe it's a little bit understandable why this particular part takes a little longer. But it's doing all that right now. It's preparing the app to deploy to Heroku. It's allocating an octa org. And it's actually going to deploy it to Heroku. So I'm going to let that run. But here's the part where we can do the old school cooking show type of scenario. And here's it fully baked out of the oven. So what you're left with is a user ID and an initial password, which is just a UU ID, which you can use to log in. And you can also, if you're familiar with the Heroku CLI, you can see the config that's been set for this octa instance. And it includes an octa org URL. It includes an API token. It's set up a couple of applications and configured environment variables for those applications. So we have a SPA, an OpenID Connect SPA app. We have a web app as well and an issue where all of this is set up so that I can now go to this app. And I called it JIP Hero Demo. And I'll bring up an incognito window here and jump over to that app. And it's probably been put to sleep through inactivity. I forgot to preload it before this. So it'll take a moment to wake up. We can actually watch that happen. There we go. So here's kind of your vanilla, you know, cookie cutter React J-Hipster app. But I have some navigation here, and I can go and sign in. And this now redirects me to this octa org that's been configured, created and configured for use with this, with this application. Now I could use the... Oh, I might have scrolled it off the screen. Here we go. I could use this other user that was set up for me. This is an ordinary user in octa. But part of the provisioning process also creates a super admin user. So I'm just going to log in with that super admin user. And you can see that all of this is changeable after the fact, but the initial user ID and password involve these random new ID values. So I'm going to paste those two bits of information in. Now I'm going to get hopefully redirected back to the application in an authenticated state. So all of that was done without having to visit the octa admin console at all. And this is running in Heroku, and it's now ready for me to customize and really build out this app, but I don't have to worry about the auth piece is kind of just taken care of here. Right. That was pretty seamless, actually. So you have an app now not only built, but also deployed to Heroku. And it is running on Heroku and already configured with octa for login. That is kind of amazing. Yeah. Oh, and one other thing that I think is worth showing here, and this is part of the Heroku experience. So I called that J-Hip Hero demo. Similar to what you would find with MySQL or Redis or any of these other add-ons, part of the requirement of building an add-on is that you provide SSO from Heroku to whatever the add-on is. So coming over here, you can click on octa and this will jump you right over to your octa org without any additional authentication required. How does that work? Oh, it's some serious voodoo involved. I'll tell you what, our Heroku, rather, peeking behind the curtain here a little bit, has a robust but proprietary SSO mechanism. They don't use a standard, which is unfortunate in my mind. I love Heroku, but I think that's a mistake. But we implemented all of that so that it would work properly. You have to implement that on the add-on, I assume, because octa doesn't support Heroku's proprietary. Correct. Yeah. So over here in the octa org, I can see that these apps that have been created, here's a little peek. Oh, there's the one for their SSO, okay. Yeah. So there is maybe a hair of fragility in there for people watching. It says, do not alter here. If you were to, say, delete this app that was created in octa, that would break SSO. So that's a little more fragile than we would prefer, but- You could still log in to your org with a pan of screwed red. That's exactly right. You never lose access to the org. The only thing you'd be breaking is this Heroku to octa SSO. So I wouldn't call it a security risk per se. It's more of a kind of user experience risk if you were to break that. But you're always a command away from the initial config, which includes a super admin login. So you can always log in directly to the octa org. You may not even want to use that SSO mechanism. So you have another way to get to that octa org if you need to. Yeah, makes sense. It's very cool. Thanks. Yeah. And we are literally, we're in beta right now with the Heroku add-on and it's literally going to GA on Monday. Oh, fantastic. Okay. So can we use it in beta right now or not till Monday? It's only a few days away. Yeah, you can use it right now. Once it gets the way that Heroku works, once it's in beta, it's publicly available. It's publicly searchable. So anybody can use it right now. That is very cool. Yeah. So happy to answer any questions about that or anything else anybody wants to talk about. Yeah, awesome. Thanks for the demo. Let's see. We do have a question. Will this video session be available for viewing after on this channel? And the answer is yes. So we will leave this stream up for viewing later in case anybody wants to. And with any luck, I'll hopefully segment out the individual demos as their own videos as well so that you don't have to scroll through a six-hour long live stream. Nice. So yeah, for the rest of the time, we will feel free to drop in more questions about OAuth, Heroku, J-Hipster or whatever into the chat. We'll answer questions. Otherwise, we're just going to keep talking about stuff. So you're going to get whatever you get unless you come with your own questions. Yeah, a lot of cool stuff going on. I think it's a lot easier to get going as a developer now with this stuff thanks to all these little tools. Yeah, I got to say, I hope other people have the same experience, but this has been kind of a fun day for me. We covered a lot of ground, did a lot of hands-on stuff. That's for any conference I attend. That's the stuff that seek out the hands-on stuff, the stuff I can kind of go along with on my own computer while watching what somebody else is doing. So I hope everybody else enjoy it too. Yeah, I hope so. We had a lot of good demos, a lot of good... The labs were a lot of fun to do that. And you got a sneak peek of the hands-on exercises without having to actually be part of the enrolled course. So that was nice to be able to do that and share that with everybody as well. Oh, this is a great question from Matt. What was the hardest part of developing the Heroku add-on? The hardest part was the SSO piece for sure. It required a little bit of API gymnastics to bridge that gap between Heroku and Anastas. Yeah, as somebody who lives and breathes in the Oauth and OpenU Connect space, I am fascinated by that part of it. But it sounds like the Heroku is actually doing the SSO to your little app that's running and that app is doing OIDC to Okta, to that app you created in Okta. Is that correct? Ultimately, yes. There's a little bit of stuff that happens in between what you just described. But yes, the last leg of the SSO interaction is to hit an OIDC endpoint having established a session with Okta. Yeah, that is some gymnastics. I feel like the double layer, two-layer SSO flows are always hard to keep track of in your head. Yeah, indeed. Even when they're both OIDC and not to mention some proprietary thing. Yeah, that's right. Do you have any thoughts on Heroku's proprietary mechanism? Is it kind of like OpenU Connect or is it like SAML or is it just something totally different? I mean, it's kind of old school. As a security professional, I'm impressed with it because it's robust, it's well thought out. The other edge of that sword is kind of just leaving me wondering why. And I've had this conversation with Heroku and again, lots of love for Heroku, but this is one decision that I find is a little bit of a headscratcher. And I guess, I mean, if I wanted to play Devil's Advocate and try to get into Heroku's head, they're dealing with businesses from Redis to MySQL to Postgres to Okta. There's hundreds of these add-ons and very disparate types of businesses. And also to their credit, their mechanism for SSO has been around for a very long time. What would make it easier on us and make it less fragile would be if Okta's back-end supported it, its core back-end. And that's just for a little bit of history. That's what we ended up doing at Stormpath way back when our engineering team actually added a little back-end support for Heroku's SSO mechanism so that we didn't have to go through API gymnastics. But my own personal opinion, without any sort of background or knowledge of what they went through, is that it would be just as easy to build and support for a standard as it would be to roll your own. So if, for instance, they supported OIDC since we have the ability to support OIDC, generally it would have been a pretty simple matter to provide SSO from Heroku to Okta. Right. Do you know when they made their initial support for SSO? Do you know when they developed it? That's a really good question. I mean it's seven to ten years ago minimum. It's been around a while. Okay. So OIDC was still pretty new at that point then I would say. Because OAuth was finalized in 2012 and OIDC builds on OAuth, which means it can't have been finalized before that. Yeah. Again, without really knowing what's going on behind the scenes at Heroku, I would say, at least from the outside, they have thousands of these add-ons and their system seems to be working. They keep getting other companies like Okta to add more add-ons. So they may just kind of think, well, it's not broke, so why fix it? It's not broke and it's been around for so long that they do have a real excuse for why it's not a standard space approach. And if they don't really gain much by switching to a standard, then there's not a lot of motivation for them. The main benefit, I would guess, would be that it would let companies like Okta integrate natively as opposed to having to spend more engineering time on the integration. So it depends on who has the power dynamics there, I guess. Right. Yeah. It's interesting. Yeah, it'd be interesting to see prior to Salesforce acquiring Heroku if it might have been a different dynamic. But if it's Okta saying, hey, go support OIDC and Salesforce saying we have this SSO mechanism, it's kind of an even match at that point. Yeah. Heroku, a Salesforce company, is kind of like, well, if you want to have an add-on on our platform, here's what you have to do. Right. Yeah, that's a tough one. We have another question from the chat. So how can we delegate responsibility, for example, only team A can manage their authorization servers, set policies and rules, but other teams with their own AS can't? That's a good question. There's a whole section now for applications where you can use OAuth for apps and there's a pretty fine grain of scope control. I don't know if that's one of them off the top of my head. I could take a look. I don't know if, you know, control of authorization servers or a particular authorization server is one of those scopes. I do believe that there's an Okta admin type that is, I'm going to look at this right now real quick, but I believe there's an Okta admin type that is like an OIDC manager or an authorization server manager, and you can limit that type of administrator to one particular authorization server. So they could add new scopes or new claims, they could assign which apps can use that authorization server, but they wouldn't be able to do that in any other authorization server for the same Okta or. I'm going to double check on that right now and I'm going to use the SSO from Heroku to Okta to do it, just to check it out. Why don't I share my screen again real quick and we'll go on this little journey together. So let's see, if I go to security and administrators, this is one way that I'm thinking of, and here's admin types. API access management is an admin type and I'm not entirely sure what that gives you access to. So let's go to types, this is moving to developer section, go to developer.okta.com, look for administrator roles, how about that? Oh, rabbit hole alert. Is it describing the API for it? What about just concepts for administrator roles? Let's take this back to Google. That's the API reference, that's help. Let's see, there's somewhere in our docs and I should be able to find it more easily that we have a table of these admin permissions. Yeah, that makes sense. All right, well, can you just try it? It's a little bit of a fail, but I'll see if I can find it and if I do, we'll go from there. Yeah, but anyway, the overall goal of what you're looking for is creating a user with a specific set of permissions? Yeah, I think the idea would be you have a user and you can assign that user an admin role like API access admin and that would give them control over an authorization server where they could configure that authorization server on whatever way made sense, but they wouldn't have access to other authorization servers. So you could kind of partition out your administration that way if you have multiple authorization servers. So that sounds like, okay, yeah, it makes sense. Using authorization servers to segment who can manage them. Right, which hopefully I didn't miss the nature of the question altogether. It seemed like that's what they were asking. Yeah, well, speaking of multiple authorization servers, that was actually something that came up during Chris's lab earlier. He was talking about using multiple API or multiple authorization servers to segment out different aspects of your own API and your own access control, which I think is always a question people ask is why would you want to add more than one authorization server or when might you need more than one? And I get some good examples in there, I thought and yeah, it's interesting. So the way it works in Okta is the one authorization server gets one audience claim. So this is the idea is that the authorization server issuing access tokens will put a particular audience string into the access token and the audience is meant to represent the API that it is protecting. So basically you would have one authorization server per API that you are building. Now you get to decide what the scope of that API is because your one API could actually be an API gateway to a bunch of backend microservices and nobody cares about the difference between that. But you could also decide that your API that you're building is actually a bunch of different logical APIs and you might have an API for processing actual orders like taking orders and doing the checkout flow and a separate API for managing the product catalog where those are pretty different APIs even if they share the same backend database. And then it makes sense to have multiple like one authorization server for each one because those access tokens aren't going to be used by the same app talking to both of them right. You're going to have your application for your staff to manage the inventory and a separate application that's your public facing app that's your shopping you know your catalog and shopping cart. So I think that's a nice example of when it makes sense to use multiple authorization servers and how you might use those different audience values. Yeah. Did you find it. I think I did find a reasonable reference here. Let's. I got it. Oh was I still sharing my screen. No I just wish I had you. Nice. So you can see my screen now yeah. Yeah. Sweet. So this is in our in our help center and it's kind of this massive table of all the different admin roles but it has this API access management admin role that you can assign to a user. And it kind of covers the things that I was talking about. So like you can this may be like super small for people but you can you can add delete edit authorization server scope claims and policies. You can you can view users that are that are assigned to the but is that across is that across all authorization servers or can you assign it to a particular authorization server. I believe that you can assign it to a particular authorization server. Let's just see if I add an admin role to this J. Hipster user. Right now this is an ordinary user that was set up as part of that J. Hipster. So I'm going to say API access management administrator. And then I should be able to actually now I didn't have to like assign this user to any particular authorization server. So maybe it is not entirely clear to me but it looks like it might be general overview of any authorization server. So maybe that's a good feature request. Right. Yeah. And now I think I did change the password on this array. So let's go see what I can do. Yeah. So it looks like I can add a new authorization server and then it looks like I can mess around. But you can still change the one. Yeah. Yeah. Yeah. That's yeah. Well let's get a feature request being able to assign assign users to specific authorization servers. Yeah. Indeed. So yeah file that as a as a where is it the ideas website I guess. Where is that. Ideas. Octa.com just drops into a log in. I think that is the right site though. Anyway. Yeah. Good question. Oh and Josh says I saw there was something on a future robot for more detailed roles. So maybe it would be part of that enhancement. I don't know if that is the case but that that is hopeful. The whole OAuth for Octa stuff is relatively new still as well. So hopefully that continues to improve in the future. Yeah. Yeah. Well cool. What else. Do you have any other ideas about multiple authorization authorization servers. Yeah. We were talking a couple of us talking a little about this earlier and you know I certainly created a bunch of apps micro services architecture or an app that for one reason or another has multiple resource servers. And when it was all kind of in the same you know problem domain of the app I just reuse the same authorization server even if it was a different resource server. But I can certainly imagine a scenario where you have very disparate services and maybe you want to you know be able to compile them or you know have different configurations for different applications where some applications can access some and some cannot or they're put together in different ways. And I could imagine having different authorization servers in that scenario where you have like a real kind of apples to oranges sort of resource servers that do very different things. You know if it's a cluster of resource services for high availability or if it's different resource services that are kind of you know in service of the same application then it seems like you could just make use of the same resource server which is actually kind of handy because then you know you have an access token that yeah you have an access token with the right audience and you know you can hit different API endpoints on different resource servers with the same access token. I think another thing to keep in mind there is that you get to define policies on within an authorization server on token lifetimes. So how long you want tokens last how they should be issued depending on scopes and roles of users and all those kinds of a lot of rules you can sort of stack up to create your policies and that lives within one authorization server. So if you have rules that you may want that you may want relatively complicated rules that exist within a certain area because they're talking to certain backends it may become too complex to try to manage those rules along with a set of rules for a totally different set of use cases. So drawing a line there makes sense where you can separate those two out so that you aren't having to make sure your rules don't conflict with each other or or interfere with each other in strange unexpected ways. Yeah and that's a good you know as developers we might call that a code smell but like a policy smell if you you know if you have tens of rules in your in your policy you know it's kind of an indicator that maybe you need to break things up a little because we get a lot of help requests where I think the most common one is where somebody's not getting issued a token and they expect it to be and it turns out that you know they're they're hitting a deny rule you know before the the accept rule would have gotten hit in in their in their policy you know their their policy stack. So if you're getting into really complex policies and rules that can be an indicator that you might want to break things up a little. Yeah that makes a lot of sense well cool um any other thoughts otherwise we can we can close things out it's a little bit before our scheduled end time but I feel like we've done a pretty good overview of of a bunch of different topics today it's been a wild ride and thanks Micah for joining sure co-host of today on your very last day of work. Yeah it's been a treat but one thing I might add just in closing is for the projects that we kind of featured today um they they're all open source j hipsters open source the uh the the octa cli has an open source component to it even though there's a private back end um and uh you know same thing with the Heroku add-on and so if you know feature requests github issues um those are all you know at the the general community's disposal if there's uh if it's behaving in a way that doesn't make sense or you want to see a feature added um you know we're really these are all kind of new technologies that we want to see the developer community really embrace so we're really listening yep it looks like we have the link for the octa cli is this one and we also have a separate org for some of the developer tools as well which is um is that octa developer got on github yeah yeah oops geez clicked too many things um the yeah so this link on on github is this bunch of other demos there and then of course the uh always happen here from you as you know from filing issues on those repos and things like that uh we also have blog posts of a bunch of the content uh demos of these things that we've been talking about so leaving comments on those blog posts is a good way to get in touch as well if you have problems or questions or feature requests you know we do read the comments on the blog posts so it's not a good place to try to to get in touch with us yeah and uh josh thank you for all the questions as well that uh saw you pop up here a bunch of times so awesome thanks for joining a lot of a lot of it's a great crowd today a lot of good questions for uh developer focused content today it's been great yeah and one other link i'll just put in uh to youtube chat here this for the octa heroku add on the way to uh list issue you know post issues or ask for features is through uh heroku's elements sites since the back end of that is private source that's the best way to get our attention for the octa heroku add on cool okay is that like through the heroku's web interface yeah there's a there's a link there there's a support link there that uh you know finds its way directly to our support team and and depending on what it you know the nature of the support would find its way to us um and that would be a good place to put in issues or feature requests or anything else great beautiful yeah and what was linked to that uh that or is it just in there in the add-on once you're in the add-on well you can get to it directly from the add-on but also in the page that uh that you just had up at toward the bottom there's a support link that has a lot of the like oh that that page that you were on has a lot of overview information and you know it shows the beta tag still that'll go away on monday but toward the bottom there's a uh it also has a bunch of documentation there uh which if we've done our job right you don't really need but if you are curious you can uh you can go look at that documentation um but uh the uh the it's got some direct email support that comes that comes right back to us got it yeah great well um yeah thanks for that all right uh and i guess i guess with that we will uh wrap things up so thanks to everybody for joining today it's been a marathon of a live show so this will stick around on youtube so you feel free to watch back the replay if you want uh anytime and uh subscribe on youtube give this video a thumbs up subscribe so you can make sure you don't miss our other content because we're posting we post up here all the time and we're gonna post a bunch of the talks from from octane our developer talks here as well so you'll be able to watch those if you miss them if you miss them live during during octane 21 those will be on the channel here shortly so yeah excellent uh with that thanks everybody for joining and see you in the next video