Allow customisation of session cookie name and sameSite value.

[rxl881]

It would be useful to provide the ability to customise session cookie names. This allows for adding cookie prefixes. E.g. setting '__HOST-' and '__SECURE-' prefixes on cookie names prevents them from being overwritten by insecure origins (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie).

Additionally, allow the 'same-site' cookie property to be specified, in order to prevent cookies from being sent cross-site, protecting against CSRF attacks.

[iaincollins]

Hi @rxl881

I'm sorry I wasn't able to get back to you sooner. Thanks for your Pull Request!

Happy to say Version 2.0 is planned for later this month. However, it's a complete re-write so will I need to port this over.

The new configuration, especially for CSRF, should be a lot simpler but I'm going to leave this PR open as a reminder to review this PR and incorporate the enhancements into 2.x.

[rxl881]

Hi @iaincollins,

Thanks and no worries. Looking forward to version 2.0. Hopefully this is useful in the re-write.

[iaincollins]

@rxl881 just wanted to say thanks for raising this and to let you know I acted on it today for version 2.0 and added a 'cookies' option with the following defaults:

cookies: {
  sessionId: {
    name: 'next-auth.session-id',
    options: {
      httpOnly: true
    }
  },
  callbackUrl: {
    name: 'next-auth.callback-url',
    options: {}
  },
  urlPrefix: {
    name: 'next-auth.url-prefix',
    options: {
      httpOnly: true
    }
  }
}

Any of the names or options for these cookies can be overridden, so if I've got something wrong, things change over time (or someone needs flexibility that isn't there out of the box) then it's easy to customise and no-one should be blocked by it.

I'd appreciate input on what we think sensible names and options on them should be. I'm thinking of setting the client side accessToken (not used for anything in next-auth, but is generated to allow for an easy way to authenticate users for less privileged operations on the client).

Note: Documentation on cookies and options is still in progress, but callbackURLs are intentionally not HTTP only so that client side access can read them during client side user journeys, but all callbackUrl are checked against a callback function which can be supplied as an option, to ensure users can only be sent back to approved sites.

[iaincollins]

Happy to report that in 2.0 beta 10, all cookies now have the following properties:

• HTTP Only
• Secure
• SameSite (lax)
• Path
• Either __Secure- or __Host- prefix (depending on what they are for)

Notes:

• CSRF token cookies and configuration cookies used to control access between the client and server are signed, using a cryptographically secure hash + secret.
• Some of these rules (like secure) are relaxed on development URLs (e.g. http://localhost) which do not support HTTPS, but are other .
• The names and all options of all cookies can be individually overridden with configuration.
• Cookie max-age are not currently set (this will be resolved when session rotation is added).
• For a working demo of this in practice, see http://next-auth-example.now.sh

I'd like to thank you again for this PR which has raised these issues and I'm really glad I could incorporate these enhancements and address the issues flagged by this PR which I don't think would have happened otherwise.

I'm going to merge this in to master now, but there probably won't be a release to NPM of 1.x and 2.0 is likely to drop very soon.

[alanyong91]

can set the sameSite optional? I faced a problem if I set sameSite to none.
#2085