CODEWITHSUNDEEP
authenticationoauth-2.0oauthaccess-tokenopenid
thedethfox
thedethfox

Reputation: 1741

Authentication and third party cookies

I am trying to figure out the best way to implement cross domain authentication.

Scenario:

As a user I log in to youtube.com, when I visit Google.com by typing the domain name https://www.google.com in a new browser tab, my session is preserved.

Problem:

As a developer, how do I implement the cross domain authentication in away that is secure, future proof and user friendly?

I will use the example of Google and YouTube to explain the problem. The parties that will be evolved in this examples are:

  1. Authentication service: accounts.google.com
  2. First domain: google.com
  3. Second domain: youtube.com

Possible solution 1

Use the SameSite attribute to create a Third-Party Cookie that will be used for authentication. This cookie will be used to store and maintain the user's session cross the websites.

Example

  1. The user visits YouTube.com and log in.
  2. The service accounts.google.com issues Third-Party Session Cookie where the SameSite is set to non.
  3. When user visits Google.com, an Ajax request is made to accounts.google.com that includes the Session Cookie issued in Step 2.
  4. accounts.google.com will return the user profile and Google.com will see him as authenticated.

Pros:

  1. Easy to implement and requires minimum changes to websites.
  2. User friendly since the experience does not require any redirections.
  3. Secure since the websites that call the Auth API (accouts.google.com in the example above) can be listed as part of the CORS policy.

Cons:

  1. As of 2022 such cookies are blocked on most browsers:

    1.1 The usage of Third-Party Cookies is blocked in Safari since version 13.1.

    1.2 This year Firefox introduced Total Cookie Protection, which “ensures that no cookies can be used to track you from site to site as you browse the web.”

    1.3 Google is planning to phase out third party Cookies by 2023 and replace them with FLoC.

Possible solution 2

  1. The user visits YouTube.com.
  2. Before the YouTube is rendered, the user is redirected to accounts.google.com to check his authentication status and then he get redirected to YouTube.com
  3. The user log in to YouTube.com by first Getting redirected to accounts.google.com where he logs in and then he is sent back to YouTube.com
  4. When the user visits Google.com, he gets redirected to accounts.google.com first and issues an authentication cookie and redirects back to google.com.
  5. Google.com uses the cookie to authenticate the user and load his profile.

Pros:

  1. Requires more work than the first solution.
  2. Secure since we can use first-party cookies and a while list of the domains that Authentication service redirects to.
  3. Secure since the websites that call the Auth API (accounts.google.com in the example above) can be listed as part of the CORS policy.

Cons:

  1. User experience might be impacted because of the redirection. For example, if the Authentication service is slow.
  2. If the authentication service is down then the websites will not work as they redirect it to it as the start of the user visit the check the authentication status.
  3. The need to clear all cookies from all websites when the user logs out.

Questions

  1. Are my assumptions about the solutions 1 and 2 correct?
  2. Is there another recommended way to share the session across multiple domains?
  3. Do identity providers like Azure (OAuth2) solve this problem? How to manage the access and refresh tokens across multiple domains?

Upvotes: 8

Views: 3802

Answers (1)

Gary Archer
Gary Archer

Reputation: 29273

SOLUTION 1

Cross domain solutions have blocking issues as you have articulated. These days you need to design hosting domain names to share a base domain such as *.example.com if you want to share (first party) cookies.

An example is how in Google you can navigate between drive, mail and calendar without redirects, because all 3 apps are hosted in the same parent domain. Note that the resources involved are quite similar.

SOLUTION 2

This is the OAuth standard way of doing things. The Identity Provider cookie is third party but not (currently) dropped in any browser when there is a top level redirect in the browser, since this acts as a user gesture.

The redirect per app results in each app getting its own tokens and lifetimes with permissions specific to that app, which is cleaner from a security viewpoint.

WHICH OPTION?

I might choose option 1 for a Micro UI based architecture, where a single app is deployed as three technical conponents, or for a small set of apps with essentially the same privileges.

Option 2 is simpler to manage as software scales, and some apps have higher privileges than others. It will fare better if you have to explain your security to customers or undergo PEN tests.

I think single sign out options may be better in solution 1. It is usually seen as a secondary requirement though, and these days people understand that this is an area with technology limitations.

Upvotes: 2

Related Questions