Rules define particular token lifetimes for a given combination of grant type, user, and scope. They are evaluated in priority order, and once a matching rule is found no other rules are evaluated. If no matching rule is found, then the authorization request fails.
While in the Rules list for an access policy, you can:
Note: 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.
Access policy rules are whitelists. If you want to create granular rules, you must first ensure that you have no rules that match "any" of something (for example "Any user"). You can then create specific rules for each specific use case that you do want to support. For example, if you wanted to ensure that only administrators using the implicit flow were granted access, then you would create a rule specifying that if:
implicitgrant type, and
Then the access token that is granted will have a lifetime of, for example, 1 hour.
Rules can also be used to restrict grant types, users, or scopes. For example, you could prevent the use of all scopes other than
offline_access by only creating rules that specifically mention those two scopes. This means you would have to:
Any request that is sent with a different scope will not match any rules and will consequently fail.
At this point you can keep reading to find out how to create custom scopes and claims, or proceed immediately to Testing your Authorization Server.Next: