 Welcome to this video tutorial. I'm Simone from the Okta Developer Support Team. This video is for Okta admins and developers who often collaborate to set up OpenID Connect or OAuth 2.0 integrations. And generally anybody interested in how Okta implements these two security protocols. In this video, we will cover the different authorization servers in Okta and more in-depth will cover what is OpenID Connect and OAuth 2.0, what is an authorization server and the types of authorization servers in Okta, where to find and how to configure the different authorization servers, specifically where to find the public metadata or discovery URLs for OIDC and OAuth 2.0 integrations. And so by understanding how to configure an authorization server, you'll be able to solve common issues. In Identity Access Management, OpenID Connect or OIDC and OAuth 2.0 are two separate security protocols that go hand in hand, but can function separately for the purpose of authentication and authorization respectively. OIDC relies on claims or info regarding a user stored in an ID token issued by an authorization server to log users into your app. Whereas in OAuth 2.0, this relies on access tokens that contains info regarding a user, which will allow them access to certain backend resources. As we can see here, OpenID Connect sits on top of OAuth 2.0. And in this diagram, we see them existing separately and yet accomplishing the same goal of Identity Access Management. Now moving on to authorization servers, what is it? It's an engine trusted by the protected resource, aka your backend resource, to issue tokens to your app. Think of it as a bridge between your web app and the protected resource, allowing users access. Now let's take a look at another diagram that shows the authorization server in more detail. Here is one type of OAuth 2.0 grant type called authorization code, which is the most common OAuth flow. In this scenario, Okta is the authorization server in between your web app and your resource server, issuing a code to your web app, which is then responsible for presenting that same code back to Okta in exchange for a token to gain access to your protected resource. Here is a table of the different authorization servers and their capabilities. We have the custom authorization server, which is an add-on feature. The default template, which is a ready-made custom authorization server and the Okta Org authorization server. What I want to draw your attention to is that the Okta Org authorization server can be used to implement OpenID Connect, but if you need access tokens for your backend resource, you will definitely need to upgrade to include the API Access Management feature to enable custom authorization servers. Feel free to pause this video to take a closer look at what is available within each authorization server. And now, this is a table with all the available Okta Orgs within Okta. The free developer org, Okta Preview, and Okta ProdOrg. Notice, the free developer org includes all the different authorization servers, but the custom and default authorization servers are not included in the Okta Preview and ProdOrgs. So be sure to reach out to your account manager for more info on pricing for the API Access Management feature. Again, that is if your use case requires access tokens or OAuth 2.0. Now, let's go over where to find and how to configure the different types of authorization servers. First up is the Okta Org authorization server that lives within the OIDC application. Here is an example of an OIDC single-page application. Under the Sign On tab, and then under OpenID Connect ID token, we find the issuer, which is the URL used to request your tokens. You can also set up group claims here, which is typically used for role-based access. And I'll go in-depth about this setup in another video, but for now, just know that you can create group claims here using Okta Group Expressions. Now moving on to where to find the custom authorization server, which again is a paid add-on under the API Access Management feature, and which again comes free with all developer orgs for your testing and which I'm using in this demo. To find that, we go under Security, API, and I've opened a new tab here. Notice that if you don't have API Access Management, you would not be able to see this authorization servers tab. As you can see, Okta provides a custom authorization server ready-made template called default. Let's take a look at its settings. Under its main settings, it provides a metadata URL, which provides information about your authorization server. I'll provide more info on this later. You also have a Scopes tab, which you can use to create custom scopes. And a Claims tab to create custom claims to extract user info as needed. Under the Access Policy, Okta provides a default policy and default policy rule for you. And when you create new authorization servers, you'll need to create policies and rules on your own, but you can use the default to model after. Here you can restrict what applications get access to this authorization server, and you can also restrict token lifetime as well as scopes being asked. Lastly, we have a token preview tool to see a sample of your ID and access tokens. When setting up your OIDC or OAuth integration, the third-party service you are working with may ask for metadata, discovery, or a well-known URL. This just means the public URL containing info about your OAuth server. Specifically, the OIDC or OAuth endpoints needed to interact with your OAuth server. Let's go find where that is. So under the main settings, I had mentioned the metadata URI. If I click on this hyperlink, I'm taken directly to this public URI where I can find the issuer of the tokens, the token endpoint to get the tokens, and the keys endpoint to validate those tokens. Now, this is for the OAuth integration, and if I wanted the OIDC integration, I would go to a different public URL and add open ID configuration at the end. And here I would find, again, the issuer of the tokens, the authorization endpoint where I could get the code, and in exchange for that code, I can get a token from the token endpoint. I can then use that token to get more info about the user at the user endpoint. And again, I can take the keys endpoint to validate those tokens. I will be sure to add all the documentation I've used in this video, and specifically this documentation that details all the OIDC and OAuth endpoints in more detail. And now finally moving on to the fun part of this video. Let's break some things to recognize common mistakes and learn from them. Remember, one of the ways we can tell that an org doesn't have an authorization, a custom authorization server, is when the org doesn't have the authorization servers tab. Yet another way is when you or your developers build with one of our SDKs, which all require the use of a custom authorization server, and find the following 401 error like this. In this scenario, I'm simply calling the metadata URI of an org, which I know that does not have API access management. And I get the error, you do not have permission to access the feature you're requesting, which simply means I do not have the API access management feature. And so with that error, don't forget to reach out to your account manager for more info on pricing and to include this add-on feature to your org as needed. Another error or confusion that we typically see is when an app receives a missing group claim due to calling the wrong server. As I have shown you, these two servers, the org and the custom authorization server, are two unrelated authorization servers. However, your app can request tokens separately from both the org and the custom authorization server. I'll show you what that looks like. I have already set up a group's claim within the org server. In this scenario, I'm simply asking for a group claim that will include all the groups I have within Okta. I'm using a handy tool called the OIDCD bugger tool. And this tool is what I'm going to use to manually request a code from Okta so then I can use that code to exchange it for a token. So I already have it configured and I've included a group scope so that I could get the groups within my ID token claim. And so when I send this request, that means sometimes you'll get an error because the app includes an ID token. We don't want that, we just want the code. So once we have the authorization code, another tool I use is Postman and you can go on to our Postman collections and download the API access management collection. Within this collection, you can find the request ready made for you to exchange the code for a token. Here I'm now given the ID token that I expect the groups to be in and I will include it in this handy tool that decodes Jots or JSON web tokens for me. And here we go, I see that I have groups included. Now let's intentionally call the wrong server and see what happens. So I go back to my debugger tool, I start over and this time I'm going to call the default authorization server by adding default. I make the same call, make sure I untick ID token. This error says one or more scopes are not configured for the authorization server resource and that's true because in my default authorization server I did not include or create a scopes called groups nor did I create a claim, a custom claim with any groups requested from Okta. Lastly, you will be met by confusion and madness when you go to validate a token you know you've revoked only to find it is still active because you are calling the wrong authorization server. There are two ways to validate a token. One way is by directly calling the introspect endpoint here saving the keys used to verify the signatures of your tokens from the keys endpoint locally to your app. Again, we know where to find the keys endpoint that's in our OIDC well known URI. And here it is for my org server. If I visit the keys endpoint directly here are the key IDs used to sign the tokens. Now let's validate an ID token from Okta. We'll first use the introspect endpoint and then we'll use the keys endpoint. So first we go to our postman sandbox and remember how we were able to exchange the code with an ID token. So with the ID token we can now go to the introspect endpoint. Again, Okta has these postman collections ready made for you and all you need to do is add the ID token to the introspect call. Send that and find the ID is in fact active still and some information about it such as groups. Now let's try making the same call intentionally to the wrong server. See what that responds with. So I'm adding default here and when I add default I get this message active equal false and that is not true because we saw that it is active. It's only that we were calling the wrong server. Now let's validate the same ID token using the keys endpoint method. Again, you would programmatically save the keys used to sign the tokens in your app. So with the same ID token I am going to use token.dev to peek into the token info and one of the information given to me is a key ID which I can use to verify that in fact this was the key ID used in signing the ID token. The caveat I should mention is that the access token coming from the Okta org authorization server cannot be validated locally as it is an opaque token. Fun fact, per the OAuth spec, access tokens are really opaque tokens but here at Okta we also consider them JSON web tokens or Jots. With that said, don't try to validate it with any of the public keys provided in the keys endpoint. I'll show you what I mean. Let's start by generating an access token. I'll be using the OIDCD bugger tool. I get a code and exchange that for a fresh access token. Notice I am calling the Okta org server and let's just inspect the access token. Using the handy dandy tool token.dev, let's inspect the access token. So see or notice two things here. First, that the audience is set to Okta. What this means is that the access token is intended to be consumed by Okta and one common use case here is when setting up a service app to interact with Okta APIs, your Okta org APIs. That service is called OAuth for Okta, but I digress. The main point here is that the validation is not intended for your backend resource. So with that said, the public keys to validate the signature at the keys endpoint is not available to you. So I'll show you what I mean by that. You are given a key ID and when you visit the keys endpoint, you notice that a key ID is provided, but it doesn't match because the validation is done by Okta and not by the keys endpoint. However, you can still perform a remote or opaque remote validation using the introspect endpoint. And I'll show you how to do that. You take the access token that you were given, present it to the introspect endpoint. Oh, by the way, the introspect endpoint takes the client ID and client secret just like the access of the token endpoint. So make sure you authorize, remember to authorize with that back to where we were. Provide the access token and see that in fact it is active. Let's just for fun. Try to validate it using the custom default server. See what we get with that. And it's false and that's that lines up because this token was not minted by the default authorization server. So in all the potential pitfalls that I have mentioned, the solution is to make sure you were calling the correct authorization server. All right, that's all for now. Happy coding and integrating with Okta. Reach out to us via the support portal or our dev forums for any further questions you may have.