JWT "secure" and "SameSite" configs seem to be ignored

[brent777]

I have a Micronaut-based web-app and I have been having some issues on the authentication side. The problem is specifically related to the change browsers are undergoing where SameSite defaults to Lax and if you use SameSite: none then the cookie must be secure. I am using all of the latest stable versions, e.g. Micronaut 2.0.1.

Chrome gives me the following exception:
A cookie associated with a cross-site resource at http://xxxxxx.herokuapp.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

Unfortunately the code base is proprietary and in a private repository. I have two example ymls showing the config, for both the JWT cookie is not being set to secure or samesite: none.

  application:
    name: xxxxx
  security:
    authentication: idtoken
    oauth2:
      enabled: true
      clients:
        azure:
          client-id: ${OAUTH_CLIENT_ID}
          client-secret: ${OAUTH_CLIENT_SECRET}
          openid:
            issuer: https://login.microsoftonline.com/[REDACTED]
      callback-uri: ${OAUTH_CALLBACK_URI}
    redirect:
      login-success: ${LOGIN_SUCCESS_URL}
      logout: '/logout-handler/logout-success'
    endpoints:
      logout:
        get-allowed: true
    token:
      jwt:
        cookie:
          cookie-same-site: none
          cookie-secure: true

and

  application:
    name: xxxxx
  security:
    authentication: cookie
    oauth2:
      enabled: false
      clients:
        azure:
          client-id: ${OAUTH_CLIENT_ID}
          client-secret: ${OAUTH_CLIENT_SECRET}
          openid:
            issuer: https://login.microsoftonline.com/[REDACTED]
      callback-uri: ${OAUTH_CALLBACK_URI}
    redirect:
      login-success: ${LOGIN_SUCCESS_URL}
      logout: '/logout-handler/logout-success'
    endpoints:
      logout:
        get-allowed: true
    token:
      jwt:
        cookie:
          cookie-same-site: none
          cookie-secure: true

There is no stacktrace, an unauthorized response is returned. When I inspect the cookie, it looks like:

Set-Cookie: JWT=eyJhbGciOiJub...DYxNzA2MX0.; Max-Age=3600; Expires=Fri, 28 Aug 2020 13:17:41 GMT; Path=/; HTTPOnly

Steps to Reproduce

1. Use either configurations that I have provided above, or similar, on Chrome with the #same-site-by-default-cookies
   flag enabled if your default browser behavior is not this already. You can enable this by navigating to chrome://flags/ in the browser.
2. Try authenticate. If #same-site-by-default-cookies is enabled, an unauthorized response is returned. If #same-site-by-default-cookies is disabled, authorization completes as expected. In either case, the same warning shows up in the browser console, i.e. "A cookie associated with a cross-site resource at http://xxxxxx.herokuapp.com/ was set without the SameSite attribute, etc"

NB: You could use any browser but it seems to be the default behavior on latest Chrome already.

Expected Behaviour

Given that I have specified explicitly that the JWT should be secure and same site should be none, I would expect to see those attributes pulling through. This should cause the browser warning to go away and auth should work regardless of #same-site-by-default-cookies being enabled / disabled.

Actual Behaviour

Auth fails if #same-site-by-default-cookies is enabled with the following message in the browser console:

A cookie associated with a cross-site resource at http://xxxxxx.herokuapp.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

Environment Information

• Operating System: Ubuntu
• Micronaut Version: Latest stable (2.0.1)
• Kotlin Version: 1.3.72

Example Application

• Unfortunately I am unable to provide this currently.

I apologise if this is due to my lack of understanding of how Micronaut security works, I am fairly new to it, but I have read the docs several times and at face-value, it seems like a bug to me.

[jameskleeh]

@brent777 Can I summarize this issue as if same-site is set to None that the attribute is not set on the cookie when it should be set to "None" ?

[jameskleeh]

Closing due to a lack of feedback. I've attempted to reproduce the issue and I cannot. I'll re-open if you can provide an example application that reproduces the issue