Authorization servers
Issue access tokens for your own APIs from /oauth2/default or a server of your own, with scopes, claims and access policies
Each organization has an org authorization server at the root of its address, and custom servers under Security → API → Authorization Servers. default is there from the start, and you can add more. An app that used https://<org>.okta.com/oauth2/default only changes the domain.
| Org server | Custom server | |
|---|---|---|
| Issuer | https://<your-org>.idra.team | https://<your-org>.idra.team/oauth2/<id> |
| Audience of access tokens | The organization's own API (okta.* scopes) | The server's audience, such as api://default |
| Scopes, claims, access policies | Fixed | Yours |
| Signing keys | The organization's | Its own, at <issuer>/v1/keys |
A token from one server fails at another's introspection, UserInfo and resource checks, because the issuer and keys differ.
Settings
Audience is the aud of its access tokens. Changing it ends the tokens already issued. Active off makes every path of the server answer 404. default can be turned off but not deleted.
Scopes
The OpenID scopes are there already. Add your own under Scopes:
- Consent: Implicit asks nobody. Required asks the person, unless the app is set to skip consent. If any scope in a request is Required, the person is asked about the request.
- Default: granted when a request names no scope. A request with no scope and no default scope is refused.
- Metadata: whether discovery lists it.
Claims
A claim is an expression, the same language as SAML attributes, or the person's group names filtered by a match. It goes in the access token or the ID token, and can depend on the scopes asked for. Claims set for the ID token and not marked to always be in it are returned at UserInfo.
If an expression fails, the token is refused, because a missing claim could read as "not restricted" to your API. A null result leaves the claim out. Reserved names such as iss, sub, aud, acr and amr can't be set.
Access policies
Policies are tried in priority order, for the clients they're assigned to. In a policy, the first active rule that matches decides. If nothing matches, the request is refused, so a new server refuses everything until you add a policy with a rule. default starts with a policy that allows every client.
A rule matches on grant type, people or groups, network zone, and scopes: a request for a scope the rule doesn't list passes the rule by. It sets the access token lifetime and how long a refresh token lasts unused.
These decide what a token may hold. Whether the person may open the app is still the app's assignment, the session policy and its authentication policy, on every server: inline token hooks and MFA apply as usual. A person's acr and amr say what their session proved.
Requiring MFA from an app
An app can ask for MFA itself with an essential acr in the claims parameter, using https://refeds.org/profile/mfa. A session without MFA is sent to verify first. This works on every server, and discovery lists the values in acr_values_supported. If the session has ended by the time a refresh token is used, the new ID token has no acr and no amr, because nothing is left to prove them.
Signing out
/v1/logout ends the session and tells apps with a back-channel logout URI that got tokens from it, each with a logout token from the issuer it knows.
Token preview
Token Preview shows which rule matches a client, grant, person and scopes, and the claims the tokens would carry. It has no request, so network zone conditions don't match there.