java - Questions about JD single sign-on authentication

Question

The above picture is an http request during the single-point authentication process of JD.com.

The process is as follows: That is to say, the current homepage is www.jd.com, and then authentication is initiated to sso.jd.hk by initiating a cross-domain request. This request carries cookies and the cookie is also returned in the response. The domina of the cookie returned in the response is set to the first-level domain name.

I have a few questions that I don’t understand,

(1) This is a cross-domain request. Why does the request carry cookies? Is this okay? I saw other friends saying that cookies can be carried.

For example, http://blog.csdn.net/wzl002/a... Whether to include cookie settings in cross-domain Ajax requests

But specifically about JD.com, how did he deal with it?

(2) Cookies are set in the response, but the current domain name is not jd.hk, but www.jd.com. Can this be set?
Specifically how Jingdong does it

(3) p3p is set in the response. Is the problem mentioned in question 2 realized through this?

(4) p3p can refer to http://blog.csdn.net/ghj1976/...

The article mentioned:
After adopting P3P, you can set your browser to automatically detect whether the website: collects personally identifiable information, uses this information to create user profiles, or allows visitors to refuse data collection.
P3P-capable browsers have some default options that you can choose from. Or you can customize your settings by answering questions such as what data you are willing to share and what types of cookies you are willing to accept. As you browse the Web, this software determines whether your privacy preferences match the website's data collection practices.

My understanding is: A browser with p3p function can detect the writing of cookies across domains, and ask the user by interacting with the user whether he agrees to writing cookies across domains? Similar to the frequently occurring web page alter prompt interaction? ? ? ? This understanding seems unreasonable,

Please say a few words (＾-＾)

Answer 1

1. Understand the difference between domain names and hosts. For example, www.jd.com is the host name, not the domain name, and jd.com is the domain name. In the picture below, if hostOnly is checked, this cookie will only work on this host. Changing the host name www1.jd.com will not work. But if hostOnly is not checked, this cookie is valid on any host under this domain name. Even if this cookie is created on www.jd.com, it can still be read on www1.jd.com This cookie, that is to say, when the browser visits www1.jd.com, this cookie will be sent to the server as part of the request.

1. Ajax cross-domain is different from this. Ajax confuses the difference between domain name and host. From the perspective of Ajax, as long as the request is not initiated on the same host, it is considered cross-domain. For example, if you initiate an ajax request from www.jd.com to access the content on www1.jd.com, this is also considered cross-domain. Strictly speaking, this only counts as cross-host, not cross-domain. However, due to historical reasons, it has always been defined this way, so there is no way to correct it.

Answer 2

My suggestion is to design the token verification method yourself. Cookies and http request responses are just ways to pass the token. If you store this token in redis/memcached, all nodes can query the current status (whether it has been verified) through the token, or write an independent service to provide verification for the same reason. sso.jd.hk uses cookies to save information such as verification tokens and timestamps.

The token does not need to be kept secret, just reply with the token directly. This mode is also suitable for websocket authentication.

Commonly used calculation methods:token = sha1(数据ID+过期时间戳+验证密码)

Send the token, data ID, and expiration timestamp to the client. When sending a request to other services, attach these three pieces of information. Because only the server knows the verification password, you can verify whether the request comes from another service. The AWS resource verification method is similar to this, except that the verification password is replaced by your API key.