Setting custom HEADLESS_TOKEN_STRATEGY

[bendajam]

I'm setting a custom token strategy, but it doesn't seem to be pulling in the class I'm setting for it. here is the settings file line to set the custom class

HEADLESS_TOKEN_STRATEGY = "app_web.views.auth.validators.SessionTokenStrategy"

and here is the class. I'm expecting to run. I'm just setting it to "hello" to see if it changes the sessionID but it does not seem todo anything.

should I be aware of failure states that don't bubble up? it seems like it's not overriding the class for some reason.

`
class SessionTokenStrategy(AbstractTokenStrategy):
def get_session_token(self, request: HttpRequest) -> typing.Optional[str]:
token = request.headers.get("x-session-token")
return token

def create_session_token(self, request: HttpRequest) -> str:
    session_key = request.session.session_key
    if not session_key:
        request.session.save()
        session_key = request.session.session_key
    return "hello" #session_key

def lookup_session(self, session_token: str) -> SessionBase | None: 
    return None

def create_access_token(self, request: HttpRequest) -> typing.Optional[str]:
    user = request.user
    logger.error("we tried to login user", user)
    if user is authenticated:
        logger.info("we tried to login user", user)
        token, _ = Token.objects.get_or_create(user=user)
        return "hello" #token.key
    return None

`

[bendajam]

Also here is the callback cookie info

refresh=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoicmVmcmVzaCIsImV4cCI6MTcxNzYxMjkwNywiaWF0IjoxNzE3NTI2NTA3LCJqdGkiOiIyYWI2ZTFlMzBiY2M0OTVhYTBhY2I5MDZjZWExNzhkYSIsInVzZXJfaWQiOjIsImZpcnN0TmFtZSI6ImJlbiIsImxhc3ROYW1lIjoibWV0IiwiZW1haWwiOiJiZW5AbWV0emdlci5jYyIsImxhc3RMb2dpbiI6IjIwMjQtMDUtMzAgMTQ6MTQ6NTMgVVRDIn0.ZXuUshuDb4and6-y8SNyO2ECkfC7FdQXMI2YA1uCVfc; messages=.eJztzDEKgDAMAMCvlMyhiODuHxxFSq2xVJoIRgd9vb7AF2S94cYRQth0l8CkGjMBNth2CMOV0ifrVevttGShxRVxUd1MskUusjCdT6ajzxxL9WlnDwgwoZVWWmmllVb-ldMLlj5Cyw:1sFGAX:BSjapd4bThuD11ump0XHeto7B207yYwpmCcGZvKOUwA; csrftoken=jdejnDwf3T9xMdIw4NSansEZgpKFzYS6; sessionid=urugb22jukj6yhbgaqrl1fhzp53pb88u

[pennersr]

Are you running this in a browser, or app context? Given that I see cookies being mentioned, I assume a browser context. In a browser context you cannot alter the session part of the token strategy as in that use case it simply uses whatever Django session backend you have configured. So, if you want to deal with sessions differently you will need to alter your Django session backend.

[bendajam]

I see so when I alter the token strategy, that doesn't mean different cookies refresh token etc will be sent back in the callback set in the headless login request?

[bendajam]

I made the mistaken assumption that providing a new sessiontokenstrategy I could provide my own cookies on the returning response to the front end

[pennersr]

The intent of the token strategy is lacking documentation. The main use case for altering the token strategy is to be able to influence the creation of an access token. It is indeed not about altering cookies et al. If you want your own cookies, you can do so using the regular Django settings.SESSION_COOKIE_NAME et al.

[bendajam]

What would your suggest for being able to use your headless allauth to then provide jwt tokens in the callback to my front end application? I'm not using sessions to check if a user is logged in but an access token paired with a refresh cookie.

[pennersr]

You can use your own token strategy, deriving from SessionTokenStrategy and then implement this method...

    def create_access_token(self, request: HttpRequest) -> typing.Optional[str]:

... to hand out a JWT token to your frontend.

As for the refresh cookie, having that cookie is proof that the user is allowed to interact with the backend. How is that different from a session cookie? As in, suppose you would do settings.SESSION_COOKIE_NAME = "refresh_token" -- how is that different from the setup you are trying to achieve?

[bendajam]

Ya, this is pretty much the goal. I appreciate you taking the time to explain.

[semihsezer]

@pennersr What is the main use case for overriding TokenStrategy? Is it just to customize how to issue session tokens and their cookie names etc.?
I am trying to see if I can override it to use JWT tokens and not db sessions in allauth, but I need to overwrite create_session_token, get_session_token and lookup_session, which are all about django sessions. So this indicates that AllAuth always wants to have a django session in the backend? Is that correct? Thanks for your help in advance!

[pennersr]

For authentication purposes, yes, a session is needed. That is unavoidable, the authentication process is a stateful process. However, once authenticated, the token strategy can be configured to hand out e.g. JWT access tokens so that further communication with your other APIs is not session dependent.

[semihsezer]

@pennersr thanks for explaining! But isn't one of the main goals of a token (jwt token, not a session token) replacing the session? From what I understand, a valid token (like JWT) by itself is proof that the user who has it is authenticated, so there is no need for a db lookup in general? But maybe you are saying that in AllAuth context that AllAuth always works with a Django session?

[pennersr]

so there is no need for a db lookup in general?

Sessions don't imply DB lookups -- you can use e.g. Redis backend sessions. Note that even when using JWT you will need to perform such lookups as well, how else are you going to support logout?

are saying that in AllAuth context that AllAuth always works with a Django session?

For the process of transitioning anonymous users to authenticated ones, yes, sessions are needed. Once authenticated, you are free to issue a JWT based access token -- which is what the create_access_token() method is meant for.

[sunpeinju]

@pennersr Is there an example that demonstrate the app context based login flow? The react-spa is based on browser context, and I don't know how to trigger the login process under the app context

[sunpeinju]

@pennersr I need to call another microservice integrated with KeyCloak witch uses JWT token to protect its endpoints. The DJango part is just lucky enough to serves the GUI and can benefit from the direct session protection, but unlucky to get the access token directly. Do you think the micro-service accessing for browser based application is a valid scenario for allauth to support?

[pennersr]

Must admit, not sure about that. It would considerably increase the complexity if allauth would need to support that in a general fashion:

• I now understand you're not interested in an access token that represents the authenticated user in the Django app, but rather a resource over at Keycloak.
• Given that allauth supports multiple providers, an access_token entry in the meta wouldn't cut it, you would actually need to be able to have multiple access tokens, for all enabled providers.
• What about the life cycle of that token? You likely cannot guarantee that the life span of that Keycloak access token matches that of the Django session, and if the access token is no longer valid, and the session still is valid, what would you do? Note that some providers use refresh tokens, which would also need to be handled somehow.
• For some providers/use cases, depending on token scope, you likely wouldn't want for that token to be exposed to the frontend and rather proxy access to the upstream API via the Django backend so that you can perform additional security checks.

As you can see, this quickly becomes very convoluted, but can likely be kept rather simple if you focus just on your project specific use cases.

[sunpeinju]

@pennersr very appreciated for your patient explain. As you said, I want to also expose the refresh token to browser to allow it renew the access token. I agree it is very complex to support such a case in allauth, but is it possible to reuse AbstractTokenStrategy subclass to expose the token I want under browser context?

[pennersr]

Currently not, as the token strategy is behind an if client == app:

https://codeberg.org/allauth/django-allauth/src/branch/main/allauth/headless/internal/authkit.py#L77

Though, we might consider removing that if.

[sunpeinju]

@pennersr Maybe move the if control into AbstractTokenStrategy.create_access_token_payload(request), keep the default behavior and let the TokenStrategy subclass to make the final decision?