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.pemalg:RS256out-var:$jwtclaims: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.pemalg:RS256out-var:$jwtclaims: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.pemalg:RS256scope-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).