The API has one endpoint with a path parameter p indicating the project identifier and two operations (GET and PATCH). The whole API is secured with a security scheme labelled "JWTCookie".
FLAT will make sure that every request to this endpoint
has a Cookie header
with a value for the authtoken cookie
that is a JWT
properly signed and
not expired.
In addition to this, FLAT provides features for further checks:
For example, you can ensure that the token was issued by a specific token provider (iss claim)
…
x-flat-jwt:
key:
file: pubkey.pem
alg: RS256
out-var: $jwt
claims:
iss: "https://trustworthy-token-provider.com" # ⬅ the mandatory value for the iss claim
…
and that your API is (one of) the intended audience(s) for the token (aud claim)
…
x-flat-jwt:
key:
file: pubkey.pem
alg: RS256
out-var: $jwt
claims:
iss: "https://trustworthy-token-provider.com"
aud: "https://my-api.com/" # ⬅ a mandatory value for the aud claim
…
A JWT with the following claims will pass the test:
FLAT will now look for a scope claim (default claim name is scope) with a value of write. If the write scope is present (possibly along with further scopes, like in "scope": "read write create"), the request passes, otherwise it is rejected.
BTW, you can specify another claim name for scopes using the scope-claim property of x-flat-jwt:
…
x-flat-jwt:
key:
file: pubkey.pem
alg: RS256
scope-claim: sc # ⬅ look for scopes in the sc JWT claim
…
The post-check flow
Finally, we want to check that a certain non-standard JWT claim pid matches the path param p (the project identifier).