Create access policies
Access policies control which clients can interact with an authorization server. They also define the access rules, such as allowing only specific scope requests.
- Choose the name of an authorization server.
- Choose .
- Provide the requested information:
Name
Description
Assign to All clients, or select The following clients: and enter the name of the clients covered by this access policy.
While in the Access Policy list, you can:
- Set access policies to be active or deactivate them for testing or debugging purposes.
- Reorder policies to change the order of evaluation.
Okta evaluates these policies and the rules within the policy in the given priority order. After the first policy and rule match, Okta applies the client request and no further rule or policy processing occurs.
Create Rules for Each Access Policy
Rules control the mapping of client, user, and custom scope. For example, you can specify an access policy rule that if the user is assigned to a client, then custom scope Scope1 is valid.
When you create a rule, Okta assigns it to the lowest priority of the rules in that policy. This action is done so that it doesn't interfere with requests that match the existing rules.
- Choose the name of an authorization server, and select Access Policies.
- Choose the name of an access policy, and select Add Rule.
- Enter the requested information:
Rule Name
IF Grant type is: Select the grant types that you want to use. Click Advanced to see more grant types. See Configure Direct Authentication grant types for descriptions of each grant type.
Select the Client-initiated backchannel authentication flow (CIBA) option to configure the authenticator for use with the CIBA grant type.
AND User is: This option only appears if you select an option under Client acting on behalf of a user. You can choose Any user assigned to the app, or define the users further.
AND Scopes requested: Choose the scopes (any scopes, or a list that you specify) granted if the user meets any of the conditions.
THEN Use this inline hook: If applicable, choose an inline hook. See Inline hooks.
AND Access token lifetime is: Choose the length of time before an access token expires.
AND Refresh token lifetime is: Choose the length of time before a refresh token expires.
Under the Refresh token lifetime, enter a time period during which the token must be used to validate and continue its specified lifetime.
The expiration period must fall within the access token lifetime and the refresh token lifetime. The maximum expiration period is five years. Tokens not used during the expiration period expire even if their lifetime is unlimited.
- Choose Create Rule to save the rule.
While in the Rules list for an access policy, you can:
Set a rule to be inactive for testing or debugging.
Reorder rules, except for the default rule in the default policy. Okta evaluates rules in priority order, so the first rule in the first policy that matches the client request is applied and no further processing occurs.
Service applications (client credentials flow) have no user. If you use this flow, make sure you have at least one rule that specifies the condition No user.
Click the information icon or rule name to see which users and groups the rule applies to, and the scopes granted to them.
