# JWT token is "invalid signature"?

**URL:** <https://community.auth0.com/t/jwt-token-is-invalid-signature/105796>\
**Category:** Get Help\
**Tags:** login-experience, new-universal-login-experience\
**Created:** [April 29, 2023, 10:40am UTC](https://community.auth0.com/t/jwt-token-is-invalid-signature/105796 "2023-04-29T10:40:57Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![peter.fernandez](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/peter.fernandez/32/45477_2.png) [@peter.fernandez](https://community.auth0.com/u/peter.fernandez)\
**Post date:** [May 12, 2023, 9:47am UTC](https://community.auth0.com/t/jwt-token-is-invalid-signature/105796/16 "2023-05-12T09:47:31Z")

</div>

> [@kkrp1](#):
>
> Given what you said about the Auth0 user database not being intended for general purpose, is this a bad idea, and instead, as you allude, I should store these permissions outside of Auth0?

That really depends on the complexity of the permission list you’re planning to store 🙂 If you do end up going down the metadata route, then I would recommend using user `app_metadata`; user `user_metadata` is user self-modifiable, which is typically something you would definitely **not** want users to be able to do! Alternatively, perhaps take a look at something like the [Auth0 FGA](https://docs.fga.dev) project? It might be just what you’re looking for - or if not, at least give you some ideas 🕶

> These permissions need to be retrieved on every request to my back-end API. (I could cache them, but I’m trying to build my API statelessly). Since they come from `/user_info` , i.e. the authentication API, not the management API, I figure I’ll be OK with rate limiting.

This sort of fine/finer grained authorization use case is not uncommon. And for these scenarios the recommendation would typically be to add the authorization permissions as one or more custom claims to the _Access Token_ JWT. Assuming the permission complexity won’t end up bloating the JWT that is. You can also add the same custom claims - or some additional (custom) claims based on the permissions - to the _ID Token_ JWT too, if the UX needs to reflect what the user is allowed to do. Remember JWTs are signed, so it’s impossible to tamper with the data. And because JWT contents is easily (machine) decoded, you mitigate any additional API calls (e.g. the call to the `/userinfo` endpoint from step 4 in the flow above) 🕶

---

_[View the full topic](https://community.auth0.com/t/jwt-token-is-invalid-signature/105796)._