how can i add claims to a litestar jwt Token

[unique pine]

the title basically. i thought adding values in extras makes those claims but when i did verify claims its failing so how do i add claims?

[unique pine]

[dapper yarrow]

Code please

In general, you should start with an MVCE

[unique pine]

encoded = Token(
            exp=exp,
            sub=str(user_id),
            extras={"user_type": user_type, "user_locked": user_locked},
        ).encode(settings.app.ACCESS_TOKEN_SECRET, settings.app.JWT_ENCRYPTION_ALGORITHM)

i did this because i thought whatever i put in extras those are the claims for the jwt token

then in my middleware i do this

token = Token.decode(
            encoded_token=encoded_token,
            secret=settings.app.ACCESS_TOKEN_SECRET,
            algorithm=settings.app.JWT_ENCRYPTION_ALGORITHM,
            verify_exp=True,
            require_claims=["user_type", "user_locked"],
        )

but i get the error that those claims arent present

so i am assuming this isnt the correct way to set the claims

[unique pine]

bump

[shy gull]

There is "user_locked" key in the token extras, and "locked" in require_claims, it's a typo?

[unique pine]

Ya its a typo i first named it locked and now user_locked so maybe forgot to change dont worry about it

I cant seem to find a way to add claims

[shy gull]

Right, require_claims checks the keys in the root of the token payload. Extras should be merged into the payload.
I guess you need to create an issue

[unique pine]

Yeah ik what it does, but i dont think there is a way to add claims to the token in the first place, there is no field for it in the Token dto

Jwt claims are ment to be as the keys in the main payload, that is correct but there is no way in the litestar jwt token class i can add claims

Iirc asp.net allows you to pass an array of claim objects which has the claim type and value

[dapper yarrow]

so, my $0.02. if you are trying to add user_locked as a claim, that's not the correct way to handle this

you are mixing up authentication with authorization in this case and it's causing you confusion. Your checks like "user locked" and the "user must be a certain type" should be implemented as guards

what happens when you lock a user account in between request after you've signed the jwt?

you shouldn't treat the JWT as if it's a session state

now, re: your ask about claims

you can add whatever you want to the token. There's a few examples in here how i use it for IAP autentication. There's extra claims added to that token.

it sounds like you want to add a public claim to the token

https://docs.litestar.dev/2/usage/security/jwt.html#customizing-token-validation

[unique pine]

So what should i use to store the user type, user type is just 0 or 1 which stands for admin and normal user, i dont want to fetch thw user from db on every call thats why i stored the important fields in the token only like the type and if they are locked, also yes i havent thought of a way yet in whixh if i update the users locked or type attribute then what to do, can you point me to the right way to do this ? Beacuse i dont want a db call definitely for each request

[shy gull]

As @dapper yarrow said, you can extend Token class and override decode_payload method, where merge the extras into payload

[unique pine]

Ya but to pass claims to that function ill have to ovveride the function signature

Also cofin already pointed out that I shouldn’t be doing it this way because i am confusing authorization and authentication so what would be the correct way

[shy gull]

Yeah, you need to override the encode method

As for the second question, I'd store in jwt only the params that change never or rarely. Otherwise, you will need a token revocation mechanism.

Like blacklisting tokens, or short life access tokens + refresh tokens

[unique pine]

Iirc role based authorisation is based on storing the role of the user in the jwt token only

So i was trying something similar

[unique pine]

@dapper yarrow i ended up making my own token class which doesnt inherit from the one litestar provides because i had different requirements, what i wanted to ask now is why did you say i am mixing authentication and authorisation, i have seen most of the people do role based access control by storing the role as a claim in the jwt token, so do you have a better way or something but do keep in mind i am not wanting to make a db request on every http request and populate the user

[unique pine]

[stiff plume]

well, one can just blacklist the JWT by its jti

[dapper yarrow]

That sounds like a DB lookup though

or a Redis call

[stiff plume]

the guard is the same, perhaps even more complex query, no?

[dapper yarrow]

well, i'm not really sure what the user wants. Everything he's looking for is already built in but it sounds like the have some unique requirements. It's impossible to blacklist a token that's already been signed without some sort of serverside change. (at least not that i'm aware of)

I think it's probably fine to make a DB user call per request

it's either a k/v DB or relational DB that needs to hold the blocklist of the server side

same for user profile state. you shouldn't really encode that kind of data in the token imo

[unique pine]

i dont think i am able to explain well enoguh, but i certainly didnt need my token to be like how the library defined it to be, i was looking for more of a asp.net style token class.