is the author suggesting allowing the client to set their own claims and using that to auth whatever action they are going to take? I have to be misunderstanding what they are saying - that sounds fraught with risk
(Author here) The JWT signer should be the authority setting claims, so if your server is the authority and the client is untrusted, the server can provide the client a pre-signed JWT with the claims it needs, and the client can send that along with requests to the API.
But this scheme is flexible. You could also have the client send "requested" claims for the server to consider adding if allowed when getting a JWT.
You could also reverse-proxy client requests through your server, adding any claims the server allows.
Comments
is the author suggesting allowing the client to set their own claims and using that to auth whatever action they are going to take? I have to be misunderstanding what they are saying - that sounds fraught with risk
(Author here) The JWT signer should be the authority setting claims, so if your server is the authority and the client is untrusted, the server can provide the client a pre-signed JWT with the claims it needs, and the client can send that along with requests to the API.
But this scheme is flexible. You could also have the client send "requested" claims for the server to consider adding if allowed when getting a JWT.
You could also reverse-proxy client requests through your server, adding any claims the server allows.
In some apps, the client may be the signing authority (e.g. it owns the resource it's accessing).
In that case, the client can possess the JWK keypair and do its own signing.
Some engineers forgot the secret/salt part of generating the jwt. Sometimes you can just pack some claims in there and encode it and it works!!