Remove problematic customization of session callback

[ulrikandersen]

Description

This PR fixes the customization on the Authjs session callback.

The customization was suppose to only add id to the user object of the session callback response (exposed via /api/auth/session), but when the previous customization, the callback also started returning otherwise secret information - namely the "sessionToken". This is really unexpected and poses a security risk.

It is especially a problem because the session token is suppose to only be stored in an HttpOnly cookie in the browser and on the server side (database), making it inaccessible to JavaScript. But with the /api/auth/session endpoint returning the session token it is easily accessible from JavaScript by doing a network request.

Reading the session token from JavaScript is problematic because it can be used as part of a session hijacking attack using XSS.

With this fix the session object is explicitly constructed to follow the DefaultSession (source) with only the user.id added.

Motivation and Context

With this seemingly innocent modification to the session callback (which is clearly documented in Authjs documentation)

callbacks: {
  session({ session, user }) {
    session.user.id = user.id
    return session
  },
}

the GET /api/auth/session endpoint starts returning a lot more session information:

{
    "id": 27,
    "userId": 5,
    "expires": "2024-12-06T04:43:00.371Z",
    "sessionToken": "abcdefg-4fb0-4145-9787-421e3465bc49", <---- !!!
    "user": {
        "id": 5,
        "name": "Firstname Lastname",
        "email": null,
        "emailVerified": null,
        "image": "https://avatars.githubusercontent.com/u/114411111?v=4"
    }
}

Without the modification the response looks like this (which is safe and expected):

{
    "user": {
        "name": "Firstname Lastname",
        "email": null,
        "image": "https://avatars.githubusercontent.com/u/114411111?v=4"
    },
    "expires": "2024-12-06T04:43:00.371Z"
}

The root cause is likely that with the modification the callback starts returning AdapterSession (source) instead of Default Session (source).

With this PR only the user.id and property is added:

{
    "user": {
        "id": 5,
        "email": null,
        "name": "Firstname Lastname",
        "image": "https://avatars.githubusercontent.com/u/114411111?v=4"
    },
    "expires": "2024-12-06T04:43:00.371Z"
}

Screenshots (if appropriate):

From the Authjs documentation (https://authjs.dev/guides/extending-the-session#with-database).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

[simonbs]

@ulrikandersen Do you know if this has any consequences? Will removing the user ID break anything?

[ulrikandersen]

@ulrikandersen Do you know if this has any consequences? Will removing the user ID break anything?

I have been testing locally with both an empty database and with existing users and I have not found it to break anything. Perhaps it is a leftover from when we were working on the separate guest flow.

We are accessing the session.user object in UserButton, but we do not use the id.

We do however have a getUserId method in AuthjsSession. I will look more into where it is being used.

[ulrikandersen]

@simonbs We do have some functionality which depends on the user ID (PersistingOAuthTokenRefresher) so in order to not break functionality I now construct the session response to include the user ID (and only the user ID 😁).