Microsoft Passport & Windows Live ID Service

Microsoft Passport

Unified login authentication service, MS maintains the user's account and password, and provides login authentication service
Authentication Mechanism:
1. When the site is added to the Passport Network, the Public Key is obtained. Communication between the site and the Passport Server can use digital signatures, encryption methods, digital signatures and encryption reference http://www.cnblogs.com/RicCC/archive/2007/03/11/WSE-Security.html
2. The site delegates login authentication to the Passport Server
3. After the Passport Server successfully logs on to the user for authentication, it packs PUID (Passport Unique ID) and authentication time to generate a ticket (ticket) and sends it to the site (Signature and encryption)
4. The site unsigns the ticket and obtains the authentication result.
Aspects to be processed:
1. The site cannot verify the login information to the Passport Server every time, So ticket is cached in the cookie. The Passport Server cannot access the site's cookie, so the action of saving the cookie must be performed by the site.
2. ticket requires effective management. For example, for a valid time of 30 minutes, ticket needs to be re-sent to the Passport Server to request a new ticket.
3. multi-site login problems. For example, if A user has passed Site A's Passport authentication, the Passport Server records its cookie information on the client, so that the user needs to log on to the Site B that has joined the Passport Network, supports automatic background logon.
4. log out. Store various logged-on sites in the cookie, and call the logout processing page for each site upon exit
Cookie Information of the Passport Server:
MSPAuth: MS Passport Authentication, which stores encrypted ticket, including: Last refresh time, last manual Logon Time (unlike Automatic Logon), password tag, and other tags
MSPSec: MS Passport Security, which stores the cookie value in SSL-enabled browsers using HTTPS, including SSL-encoded PUID and password for Automatic Login
MSPVis: MS Passport Visited Sites, stored after the current login access, login needs to return to the call Site List, store the site ID list, not encrypted

Detailed process:

1. First Login
A) The user needs to log on to the authentication page in Site 1 request. Site 1 checks the cookie and finds no logon. a logon prompt is displayed to the user.
B) the user clicks the login button and the login authentication request is directly delegated to the Passport Server.
C). Because it is the first logon, the Passport Server displays the logon page to the user (the Passport Server can read its own cookie to determine the user's logon authentication on the Passport Server)
D) The user submits authentication information such as account and password to the Passport Server.
E ). the Passport Server performs logon verification. After the verification is successful, two tickets are generated (the ticket contains the user's PUID, timestamp, and other information ), 1 copy is passed to site 1 as QueryString (this copy uses site key encryption), 1 copy is saved in the cookie of the Passport Server domain name (MSPAuth, this is encrypted using the Passport Server key ). The MSPSec and MSPVis items are also generated in the cookie of the Passport Server domain name. Finally, redirect the user interface to site 1.
F) site 1 records the ticket to the cookie, and the user request page is displayed normally.
Note:
When designing Passport, there are two Processing Methods for Site 1 during step.
First, a login interface of Site 1 is directly displayed, allowing users to provide accounts and passwords. Site 1 automatically submits the interface to the logon authentication page of Passport. This method has a problem, that is, the user exposes the account and password to site 1.
The other is the process described above. Site 1 only displays a logon prompt. the user clicks the logon button and redirects to the logon authentication page of Passport, in this way, the user's account and password are only provided to the Passport Server.
The Passport Server can return tickets to site 1 in two ways. First, each site defines a processing page after successful login, accepts the ticket and writes the cookie, and then redirects to the page of the initial request; the other is to directly process the login successful on the page of the initial request, which can be implemented through public processing. After successful Passport authentication, the ticket is directly sent to the page of the initial request.
For subsequent authentication and verification, site 1 can directly read the cookie to determine whether there is a ticket expiration Policy, the site needs to process the ticket expiration and request the ticket again

2. Single Sign-on

In combination with the first logon in 1, single-point logon is easy to understand. The difference is that the Passport Server reads information from the cookie of the Passport Server after receiving the login authentication request and knows that the user has logged on. Therefore, you do not need to display the Passport logon interface to the user, directly use the Passport Server ticket in the cookie to generate the ticket for Site 2 and send it to him.
Note:
Passport is designed to implement SSO. When site 2 is single-point logon, site 2 inevitably needs to perform an authentication request interaction with the Passport Server, because both the Passport Server and Site 2 cannot access cookies, site 2 does not contain ticket information in cookies.
Just like 1. the description in the first logon can be changed in the interface process design. For example, site 2 can directly delegate the login request to the Passport Server without displaying the login information interface to the user, for Site 2, the processing method is the first login process.

3. log out

Detailed process:
A) The user can click the exit button on a site, for example site 2, and directly delegate the logout operation to the Passport Server.
B ). the Passport Server reads the list of logged-on sites from the cookie, and performs the exit logon operation one by one (including clearing the site's own cookie ticket information ), in addition, the Passport Server also needs to clear its own cookies (related to this logon)
C) redirect to Site 2. Return to the interface after logging out

4. Expiration Policy
Tickets generated for each site, which can contain information about expiration policies
The ticket contains the timestamp at which the user entered the last password to log on, and the timestamp at which the ticket was last refreshed on the Passport Server. If the site ticket expires, the site resubmit the authentication request to the Passport Server. The Passport Server verifies the login status, refresh the timestamp, and resend the ticket to the site.
For the ticket information of the Passport Server, you can also define an expiration Policy (Time Window, Time Window). When the ticket of the Passport Server expires, you are required to re-enter the account and password to log on. Whether the Passport Server bill is refreshed or not. Otherwise, it may be caused by setting the Passport Server ticket to expired when the browser is closed.

5. secure logon and Automatic Logon
You can use SSL for logon authentication. This requires that the site's return address be based on SSL. When SSL is used, the MSPSec entry is recorded in the cookie of the Passport Server.
You can use the information in MSPSec to log on automatically. The MSPSec has been saved for a long time.

Widnows Live ID Service

The Live ID Service is extended based on Passport and defines Resource Provider and Application Provider. It is not only a login authentication Service, but also an integrated platform for multiple resources and applications.

Concept:
1. Application provider: Application provider
2. consent token: The license tag, including the delegation token, refresh token, available resources and operations, expiration time, etc. It is the authorization license file provided by the user to the Application Provider through the Live ID Service, indicates the resources and operations that an Application Provider can use. The consent token has an expiration time. After it expires, use refresh token to refresh from the Live ID Service.
3. delegation token: the authentication information provided by the Live ID Service to the Application Provider when the Application Provider requests the Service from the Resource Provider, the content includes the user ID, Applicatio ID, user-authorized Offer details, and expiration information. The Application Provider cannot unbind the delegation token. Only the Resource Provider can unbind the token. The delegation token also contains the expiration information and is refreshed using the refresh token.
4. refresh token: it can be said that it is a unique identifier of the user's permission to an Application Provider. It is valid throughout the user's authorization period and can be used to Refresh the consent token and delegation token, it can only be unlocked by the renewal Service of the Live ID service.
5. Resource Provider: Resource Provider
6. Offer: includes a series of resources and a list of operations that can be performed on each resource.

The overall process is divided into Granting Consent and Using Consent.
Granting Consent requires user interaction, that is, the user determines which resources an Application Provider can perform operations on, the Application Provider automatically uses the offer (Resource Service) provided by the Resource Provider in the background based on the Consent token)

Refer:
Microsoft Passport 101

Introduction to Windows Live ID