We have a few different strategies for this. You can read through the "levels" here[0]. (We need to expand on this doc still)
Level 1: There are no grants.
Level 2: Access requires a "shared secret" in order to authenticate to the Tokenizer. If you have the secret, get API access to the Tokenizer, and you have a copy of a token, then you can create a grant. In order to use the grant, you also need a valid session for the front-end, but if you have RCE on the back-end then you can get this pretty easily.
Level 3: Creating grants also requires presenting a JWT that's signed by an upstream "Auth Provider" that also proxies traffic. This JWT is only able to create grants that are scoped to a specific session (which is identified using a "session id" inside of the JWT).
You can still create a grant every token you have access to, but you need to get a valid session to do so. In this design, the proxy strips the cookies from the request and only forwards the JWT, which adds another step to the attack (you have to be able to login to on a browser).
This requires that you put your "Root of Trust" into your authentication provider, so you would want to "split" out your authentication/session creation into another service. We have an example app + tutorial explaining this that we'll publish soon.
Level 4: You write a separate function,called a "Secure Authorizer", that accepts a session JWT and a Token in order to "authorize" that a grant can be created for a given user.
This function is deployed in a hardened container and is difficult to attack (a network restricted Lambda).
By adding this layer, you now require that an attacker is able to generate sessions for any user that they want to leak data from. Or you require them to attack the "Secure Authorizer". It's a much more painful attack for an attacker to pull off once you've integrated all of these layers.
Does that answer your question? I'll make sure go add this explanation into that levels page.
