Example: /departments/{dept}/employees/{id}

The dept and id strings are dynamic path parameters. Creating page tokens for the whole path could rapidly lead to performance issues and might also defeat the reason of using page tokens, because an attacker could force the solution to revert to master token validation by providing unique identifier to path parameters. The severity of this problem is lower, because the attacker must have access to the master token.

Possible solution:

1. make the (un)protected page options to support wildcards (e.g. /departments/.*/employees/.*)
2. provide support for programmatic retrieval of (un)protected pages so that the definitions could be generated (e.g. using JEE/JAX-RS API or Swagger/OpenID support)
3. this solution should be combined with Page tokens generated on first use are not sent back to the client #145 in a way that only page tokens for already accessed pages or page definitions (wildcard support) are returned to the UI to avoid disclosing all the available endpoints to the client