Eliminate 3rd party cookies

[laurenwalker]

A few people were unable to log into Safari today on dev.nceas and test.arcticdata

[laurenwalker]

I was unable to reproduce this issue since Safari has been working fine for me. I'll keep the ticket open in case we keep seeing this issue.

[laurenwalker]

We ran into this issue again, and determined that Safari 12 has issues with third-party cookies using the SameSite=None property. (See https://bugs.webkit.org/show_bug.cgi?id=198181). Although this should not have been an issue when this ticket was originally filed since we only starting using the SameSite property ~February 1, 2020.

We implemented a fix for Safari 12 users, but have still seen issues with the cookies in Safari 13 sometimes. (It works for Rushiraj in MacOS Mojave but not Chris in MacOS Catalina). We still haven't found a fix for this, so will keep this ticket open.

Note: this isn't a MetacatUI issue per se, but I'll keep the issue here

[laijasmine]

This conversation came up again in response to a ticket in the Arctic Data Center.

In release 2.10 notes it mentions a troubleshooting option for Safari users. However, when Amber tried those steps she still fails to login and has to switch to Chrome. I'm wondering if providing another suggestion of switching browsers might be also be helpful.

[amoeba]

Now that I look at our workaround for Safari users of having them allow third-party cookies browser-wide, I really don't like it since it exposes them to third-party cookies from other places around the web which is pretty harmful. Of course, unless they remember to re-enable the feature when they visit another site.

For datateam purposes, I think we need to simply be suggesting they use a browser which still allows third-party cookies by default. I say still because it looks like no major browser vendor will allow third-party cookies in the near future. For now, it appears Chrome and Firefox are fine alternatives, which means Edge should work too.

A larger fix is in the works to refactor how we do authentication should eventually get us around all of this.

[laurenwalker]

Agreed that a larger authentication refactor needs to happen to fix this. Everything else is just a bandaid on a slowly expanding wound

[mbjones]

The proposal is to refactor authentication in DataONE to eliminate 3rd party cookies. Comments on that proposal welcomed.

[robyngit]

MetacatUI follows the following login flow currently:

• Uses signInUrlOrcid (set in AppModel) to send the user to the CN portal /portal/oauth, which redirects to the ORCID sign-in/consent page.
  • signInUrlOrcid is referenced in PortalView, SignInView, and several templates.
• The DataONE portal signs the user in through ORCID, gets their identity from ORCID, and sets session cookies (JSESSIONID, hazelcast.sessionId).
• SignInView then polls CN /portal/token with withCredentials=true to get a DataONE JWT.
• MetacatUI uses Authorization: Bearer {DataONE JWT} for authorized API requests.

See: sequence diagram of MetacatUI's current flow

We plan to migrate to a PKCE flow, which generally works like this:

sequenceDiagram
    autonumber
    participant U as User
    participant C as MetacatUI
    participant AS as Auth Server (Keycloak)
    participant API as D1 API

    U->>C: click login link
    C->>C: generate Code Verifier + Challenge
    C->>AS: request Authorization Code + Challenge (state, redirect_uri)
    AS-->>U: redirect to login/authorization prompt
    U->>AS: authenticate and consent
    AS-->>C: redirect with Authorization Code (+state)
    C->>C: validate state
    C->>AS: exchange Code + Verifier (token endpoint)
    AS-->>C: ID Token + Access Token
    C->>API: request user data with Access Token
    API-->>C: send response

See: diagram of the proposed Dataone flow

See: nice explanation of PKCE

To support for this new flow, we generally need to do the following:

• Identify every place MetacatUI currently uses /portal/oauth and /portal/token
• Write logic for generating the code verifier/challenge
• Use the new new Keycloak endpoints (e.g. /realms/DataONE/account) (instead of /portal/oauth?)
• Handle token storage (memory or sessionStorage?) and expiry (refresh automatically?)
• Add logout handling: clear stored tokens, use Keycloak's logout endpoint
• Make sure we eliminate the use of withCredentials=true in requests (use Authorization: Bearer {token})
• Ensure that we always get a user's email address (needed for the notification service)
• Document config changes for repos

[mbjones]

Thanks for that writeup, @robyngit -- very helpful.

Use the new new Keycloak endpoints (e.g. /realms/DataONE/account) (instead of /portal/oauth?)

This will likely be another keycloak client endooint (not account), something like /realms/DataONE/metacatui

The question is how general it can be. With PKCE particularly, they say it is super important to restrict redirect URLs for the calling apps to a well-defined set, and not use wildcards in, for example, the hostname. So that makes it hard for us to use the same oauth endpoint for arcticdata.io and search.dataone.org and knb.ecoinformatics.org. But creating separate endpoints for each is hard to maintain. The recommended approach (and in many stacks required by OAuth2.1) is to only use exact string matches for redirect URIs, but you can provide a list of acceptable URIs. A good overview of the security issues is here: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-insufficient-redirect-uri-v