Tokens issued by a Custom Authorization Server are able to receive custom lifetimes or trigger Token Inline Hooks based on the configuration and order of Access Policies and Rules for that Authorization Server. If the client requests tokens with scopes beyond those covered by a given Access Rule (for example, the rule is triggered if the request is for the openid, profile, and offline_access scopes, but the client additionally requests the email scope), that Access Rule will not match, and policy/rule evaluation will move onto the next Access Rule and/or Access Policy.

To avoid this issue, ensure that the Access Policy is assigned to the target application and its associated Access Rule(s) covers ALL scopes used by that application or has no scope or group specific constraints that would cause the Rule to be skipped during evaluation.

• API Access Management
• Custom Authorization Servers
• Access Policies and Rules
• OpenID Connect/OAuth applications
• Okta Classic Engine
• Okta Identity Engine (OIE)

The token was issued based on a different Access Policy or Rule than the one that was expected. If the application, user, or request does not match the configuration for the Access Policy/Access Rule, evaluation will continue to the next Access Policy/Rule (based on the order of their assigned priorities) until a matching policy is found.

If there is no Access Policy/Access Rule combination that matches a given request, Okta will display Policy evaluation failed for this request, please check the policy configurations error, and a no_matching_policy failure will appear in the Okta System Log for the application. More details about these failures can be found in the following Okta article: "Policy evaluation failed for this request" Error When Logging Into OpenID Connect App via a Custom Authorization Server.

This can happen for a number of reasons, depending on how the Access Policies and Rules for the Authorization Server are configured, so the solution will vary depending on the desired outcome.

For example:

• The desired Access Policy is not assigned to the target application, causing the Access Rules for that policy to not be evaluated.
• The desired Access Rule is configured to be triggered only if the request for tokens includes a specific set of scopes (for example, openid, profile, and offline_access) but the application requests a scope that is not listed (for example, email).
  • NOTE: Just because an Access Rule may cover a list of several scopes, the target application only needs to request a subset of these scopes in order for the rule to be triggered. So in the example above, a request for scopes openid and profile will still trigger an Access Rule that also covers the offline_access scope, even if it does not also request the third scope.
• The desired Access Rule is configured to be triggered only for certain grant types, but the application is using a different grant type.
• The desired Access Rule is configured to be triggered only if the user is a member of a certain set of groups, but the user is not a member of any of them.

Related References

• Configure an access policy | Okta Developer
• Create access policies | Okta Docs