What you need to know about Okta Authorization Servers

What you need to know about Okta Authorization Servers

Okta provides various authorization servers for authentication for OAuth 2.0 and OpenID Connect (OIDC). Not all the available options are visible through the admin panel, unfortunately. The main difference between the authorization servers is customizability, especially regarding scopes and claims as well as availability through the Okta licensing.

Andreas is a cloud architect in Cloudworks and an Okta Technical Champion. He is helping customers on their digital Identity journey by designing and implementing complex IAM solutions. These have a high amount of automation to achieve high impact with minimal user friction.

Org Authorization Server

Each Okta tenant comes with the so-called Org Authorization Server. It is not visible in the admin panel, but always accessible through the endpoints:

Org-Authorization-Server-1536x450

The Org Authorization Servers are not customizable, but provide a wide range of claims and scopes that are suitable for most applications. For example, the Org Authorization Server supports group scopes and claims, so applications that require role or group assignment information do not require a custom authorization server.

Org-Authorization-Server-and-supported-scopes

In the Okta OIDC app, the ID token can be configured to show only groups that are relevant for the app. In the following example all Okta groups starting with "OIDCApp_Role_" will be presented in the groups claim of the ID token.

Org-Authorization-Server-and-token-configuration

Relevant Okta documentation:
https://developer.okta.com/docs/concepts/auth-servers/#org-authorization-server 

Custom Authorization Servers

Tenants with the API Access Management license SKU will see the option “Authorization Servers” in the Okta admin panel under Security → API. By default, there is always a default custom authorization server defined.

Okta-API-

Figur 1 - Default Custom Authorization Server - NOT the Org Authorization Server

The Default Custom Authorization Server can be used as a reference for other authorization servers or for testing development applications. It is already preconfigured with the standard scopes and claims.

Any added custom authorization server can be fully configured. It is not necessary to have an individual authorization server for each app, but it can make sense to separate different configurations or use cases into separate authorization endpoints.

The discovery endpoints for the Default Custom Authorization Server are:

Default-Custom-Authorization-Server-1536x404

For any additional Custom Authorization Server:

Custom-Authorization-Server-1536x404

Since the Default Custom Authorization Server is part of the API Access Management license, all users assigned to an application that is using this authorization server will count towards the API Access Management licenses. If you require API Access Management only for a subset of your users, make sure that all standard OIDC apps are using the Org Authorization Server. All your custom authorization servers (even the default one) should be limited to the exact apps that they are required for. This mainly to increase security, but also to avoid additional license costs since the API license is calculated by the amount of users with potential access to an authorization server.

Default-policy

Which authorization server to use when?

In essence all authorization servers provide the same capabilities towards OAuth & OIDC authentication. The decision about which to use in which situation can be decided by answering the following questions:

 Is the Org Authorization Server sufficient?
Usually it is, and since it doesn’t require any additional licenses for the users it should be the first weapon of choice.

 Do I need additional scopes and claims or other customizations like a special audience?
In this case a custom authorization server will be the option to go for. Also, the access tokens from the Org Authorization Server cannot be validated. If your app requires this you need to have a custom authorization server.

 Do I need to create an additional custom authorization server?
It depends on the guidelines and policies of your organization. Some separate internal and external systems, others have dedicated custom authorization servers for each application.

The important thing here is to make sure that changing an existing authorization server will break any existing applications. The amount of authorization servers is not licensed, so it might make sense to start with a dedicated test authorization server first and add the configuration to an existing authorization server when moving to production.

Okta also has an overview of the capabilities of the authorization servers.