Cookies should not be used to identify users when bearer token is provided

Today, If I authenticate on DjangoLDP instance A in client A, I get two auth means : a cookie sessionid and a JWT bearer token stored in browser localStorage. If I then authenticate to another DjangoLDP instance B in client B and that instance B is federated with instance A, I start to be in trouble : client B sends bearer token B and cookie A to server A, and server A authenticates me as user A instead of user B.

I think that the session cookie should only be used to first generate the access token, but not in subsequent requests.

moved from djangoldp#313 (moved)

Moving to djangoldp-account

mentioned in issue applications/hubl#909 (closed)

I have a look on this thx @fabien4vo and @jbpasquier

@calummackervoy @jbpasquier I would also like your opinion about the feasibility of this point.

I have identified a place where the user is set in auth/middleware.py:

        # If the user is already authenticated and that user is the user we are
        # getting passed in the headers, then the correct user is already
        # persisted in the session and we don't need to continue.
        if request.user.is_authenticated:
            return

Is that correct ?

Then, I think the following code use the bearer token to authenticate the user, is that right ?

        # We are seeing this user for the first time in this session, attempt
        # to authenticate the user.
        user = auth.authenticate(request)
        if user:
            # User is valid.  Set request.user and persist user in the session
            # by logging the user in.
            request.user = user
            auth.login(request, user)

Is that correct ?

Is that correct ?

I believe that "persisted in the session" means that the user was authenticated by an earlier call to authenticate, not that the user is included in the cookie. Is the cookie being used in authentication is someway I don't know about? @jbpasquier

The subsequent call to auth.authenticate will hit the ExternalUserBackend which will use the Authorization token to authenticate

Not that I am aware of, ever further with the new version of sib-auth there is no cookie at all, user is only auth for the current session.

@calummackervoy if there is a session, there must be a session cookie. The user is not "included in the cookie", but the session ID is. My understanding is that we should never use the session information to authenticate the user. We should only use Authorization token, even for calls that are not meant for authentication (i.e. GET any resource for example).

So all the places where user.is_authenticated is used in django code should be replaced with a Authorization token check mecanism.

That's what's done with the DPoP approach included with OIDC 0.15 & latest of djangoldp-account + django-webidoidc-provider.

The request.user.is_authenticated value is added by authent' middleware, it works based on the dpop validity in our case.

OK then everything should be OK. I'll try to make the test on the new version to validate that this problem is now gone.

@fabien4vo I meant that I don't think the session ID is used in authentication - I think JB Lemée's comment in your code sample just means "if request.user.is_authenticated is set" - meaning that some backend already authenticated it before the middleware

EDIT: Django does use the session to store the user (https://github.com/django/django/blob/main/django/contrib/auth/__init__.py#L169), but it's not un-authenticated

If that's correct, we have two different strategies :

1. We never trust the session cookie and reauthenticate the user for each request. Could this impact performances ? The drawback is also that any admin session using another user cookie will be terminated.
2. We do not use session mechanism to check user permissions. It means that any call to user.is_authenticated in any packages should be replaced by a system that get user from the token instead of the session