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.
Rules are evaluated in priority order, so the first rule in the first policy that matches the client request is applied and no further processing occurs. If you need to change the order of your rules, reorder the rules using drag-n-drop.
Note: Service applications (client credentials flow) have no user. If you use this flow, make sure that 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 has a lifetime of, for example, one hour.
You can also use rules 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 won't 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: