Authing DocsDocuments
Concept
Guides
Development Integration
Application integration
Concept
Guides
Development Integration
Application integration
Old Version
Guides
  • Quick start

  • Authenticate the user

  • Authority management for users

  • Authorization

  • Manage user accounts

  • Manage User Directory

  • Management Application

  • Become a source of federal authentication identity

  • Connect to an external identity provider (IdP)

  • Open up WeChat ecology
  • Migrate users to Authing

  • Management organization

  • Expandable capabilities

  • Audit Log

  • Configure security information

  • Configure user pool information

  • Deployment plan

  • Frequently Asked Questions FAQs

    • How to get user pool ID
    • How to get the application ID
    • How to verify user credentials (token)
    • Join table Authing in the local user and your business data
    • Impact of disabling third-party cookies on Authing
    • How to deploy a transit proxy server
  1. Guides
  2. /
  3. Frequently Asked Questions FAQs

  4. /
  5. Impact of disabling third-party cookies on Authing

¶ The Impact of Disabling Third-party Cookies on Authing

This article describes the impact of the browser blocking third-party cookies, explains the reasons, and provides solutions.

¶ The cause

Starting from version 13.1, Safari will block third-party cookies bydefault, which will affect certain single sign-on featuresofAuthing. In other similar updates, starting with Chrome 83, third-party cookies are disabled by default in incognito mode. Other browsers are also slowly making such updates to protect user privacy. Many browsers will disable third-party cookies as a security configuration feature.

If you use the login page hosted by Authing, you will not be affected by such problems. Users who self-host the login page and use the trackSession function will be affected. Because when requesting the Authing API, it is necessary to carry Authing-related cookies across domains.

When the browser sends a cross-domain requests that need to carry cookie, browser will intercept the cookie, because the Authing domain name and user accessed domain name are not of the same origin.

¶ When will these effects happen?

Safari first introduced this feature in version 13.1, and an update will be released in March 2020.This feature is enabled by default in the incognito mode of Chrome 83.Firefox will introduce this feature in the near future.Safari refers to this feature as Intelligent Tracking Prevention (opens new window),Firefox refers to this feature as Enhanced Tracking Protection.

¶ Which Authing functions are mainly affected?

¶ TrackSession

trackSession is a single sign-on function developed by Authing. The session information and user information of the current user can be obtained on any website by requesting the Session endpoint of Authing.

When Ajax cross-domain request Authing API interface is used, for example/cas/session, Authing Cookie will be automatically carried. Browser will stop this cookie, because the request does not have the same origin with the current URL. Then the cookie cannot be passed to Authing, and Authing cannot retrieve the current user's session information and complete the response. The end result is that Authing will return a response that hasn't logged in yet.

¶ How to solve it?

In addition to using trackSession, you have many other options, such as maintaining the login state of the application yourself instead of relying only on the central authentication server, and using OIDC to complete single sign-on, or using Single Sign-On (SSO) to complete single sign-on.

If you want to use trackSession, you can change the application domain name into your custom domain name from the perspective of the browser.To configure a custom domain name, please check the documentation. In this way, the original three-party cookie becomes a one-party cookie. Ajax request sent to Authing domain name and application domain are same-origin, will not trigger the browser's mechanism to block third-party cookies.

For example, your Authing application domain name is app1.Authing.cn, and your application server domain name is myapp.mysite.com. You need to use login.mysite.com to proxy app1.Authing.cn. In this way, the Authing service and your application service can be placed under the same domain.

As long as the main domain name is the same, different subdomains in the above example will not affect the same-origin policy (opens new window) of cookies.

After the custom domain name is configured, you need to modify the configuration information of the Authing related SDK, and fill in the request endpoint domain name as your custom domain name. If you call the Authing API directly, you also need to modify these request addresses to your custom domain name.

Prev: Join table Authing in the local user and your business data Next: How to deploy a transit proxy server
  • The cause
  • When will these effects happen?
  • Which Authing functions are mainly affected?
  • How to solve it?

User identity management

Integrated third-party login
Mobile phone number flash check (opens new window)
Universal login form component
Custom authentication process

Enterprise internal management

Single Sign On
Multi-factor Authentication
Authority Management

Developers

Development Document
Framework Integration
Blog (opens new window)
GitHub (opens new window)
Community User Center (opens new window)

Company

400 888 2106
sales@authing.cn
16 / F, Block B, NORTH STAR CENTURY CENTER, Beijing(Total)
room 406, 4th floor, zone B, building 1, No. 200, Tianfu Fifth Street, Chengdu(branch)

Beijing ICP No.19051205-1

© Beijing Steamory Technology Co.