[_puk]

Being able to create an anonymous access token, that in turn has certain restricted claims defined by default.

API keys kind of do the job, but they're basically deprecated through a lot of JWT providers, and you need to support two Auth systems if you're using JWT for logged in users.

Flow is:

* Arrive at website * Generate an access token without any user input (anon user with default read only privileges) * Use the same APIs as logged in users, with restricted access defined in the JWT / Auth provider.

The two sides of it, am I allowed to access this API, coupled with what can I do once accessed seem to be the basic use case for JWT.

I appreciate the response. My terminology is likely a bit off, it's been a while :)

[abhishektwr]

Assuming you are using traditional web app and not SPA, I think it’s absolutely possible to generate restricted access tokens for anonymous users either using Machine to machine (M2M) client authentication or service account (SA) client authentication basically without any user context. Many Identity as a service providers supports M2M, and platform I am in involved supports both M2M/SA (disclaimer in profile). You can effectively attach an anonymous role to your OAuth client of type M2M/SA and start issuing access tokens. For SPA it could be complicated.

[lukevp]

Assuming you have middleware that validates your JWT and sets claims on some type of user principal in memory before processing the rest of the api, why not just create the restricted claim in the middleware if there is no auth bearer in the request?