Microsoft Passport 101

...a simple explanation of the Passport web authentication protocol...

Introduction:
Passport is a single sign-on system developed by Microsoft. It allows websites who participate to unload some of the account management burden onto a shared and specialized authentication service hosted by Microsoft.
It is probably the largest dedicated authentication service on the web, as it is used by millions of Hotmail and MSN Messenger users.

It maintains a centralized list of accounts (usernames and passwords). When a Passport-enabled website needs to authenticate a user, it delegates this task to Passport, which in return provides an assertion about the identity of the user that is signed in.
The website only needs to understand these assertions or authentication proofs, but doesn't need to handle the authentication itself.
For the user, only one password is needed for a group of sites, which simplifies managing his account and improves his authentication experience.

We'll go into the details of how this is achieved.

Assumptions:
Some prior knowledge is required to understand this description of the protocol.

• HTTP redirect: a server can reply to a browser request that it should make another request to different location.
• HTTP cookies: they are domain specific, can either expire at a given time or last for the duration of the browsing session, and may be restricted to https connections.
• Cryptography: a message can be exchanged by two parties securely (can't be modified, tampered, peeked into,..) if they both know what algorithm to use and if they share a secret (symmetric) key, that is required for the encryption and the decryption.

Ticket and cookies:
Passport authentication is centered around an account identifier, the Passport Unique ID (PUID). This number is guaranteed to be unique amongst accounts and remain the same throughout the life of a given account.

Whenever a user logs into his account, Passport needs to provide a proof back to the site that requested the authentication. This proof is called a ticket. It most importantly contains the PUID and the timestamp of the last sign-in.
In order for this proof to have any value, some cryptography is used (to ensure only Passport can issue such tickets). When a site (say Site1) becomes part of the Passport network, it gets a crypto key that only it and Passport know. So a ticket for Site1 can be encrypted with that key, in order to ensure nobody else could have generated it.
Using a signature instead of encryption would be possible to proove a ticket (or other) was generated by Passport, but if any information considered private is included, then encryption is needed.

Whenever a site receives a ticket, it can decrypt it with its key, check that the authentication occurred within a certain time and then read the PUID.
But a new ticket shouldn't be issued for each page that the site wants to display. So it can be cached using a cookie on the user's browser. This way, only when the site needed a fresher ticket, does it request one from Passport.

Cookies are domain specific, so a user can have tickets saved as cookies for Site1 and Site2 at the same time. But we'll see that also brings a constraint, because Passport can't issue tickets directly as cookies in Site1 domain.
Passport also keeps cookies in its own domain, to allow a user to authenticate silently into Site2 if he logged into Site1 already (single sign-on).

For example, here are three of the cookies that get set in the Passport domain when a user logs in:

• Ticket (MSPAuth): Encrypted with .NET Passport key. Contains the .NET Passport timestamps (last refresh and last manual sign-in), saved-password flag, key version verification, and any flags set by network servers.
• Ticket-Granting (MSPSec): Sent using HTTPS protocol for all browsers that allow HTTPS cookie writes. Contains the SSL-encoded .NET Passport Unique ID (PUID) and password, used for silent sign-in.
• Visited Sites (MSPVis): Used by the Login server to compile the list of sites that must be signed out from when the user clicks any sign-out link. Each new .NET Passport participating site visited has its Site ID written to this cookie. No encryption.

Flows and options:
We'll start by looking at the flows for three core scenarios, starting with a simplified model. But we'll progressively enrich the description by mentioning more information that is stored in the cookies, as well as additional cookies and querystring parameters.

First login:
Here is the flow for the initial authentication to Site1:

Here is how you can read this diagram:

The user navigates to Site1, but now needs to get authenticated.
He is sent or redirected to the authentication servers. Because the user wasn't logged in, no cookies are present in the Passport domain. So the user is presented with a login prompt.

The form is submitted after the user types his username and password. These are checked against the account information that Passport stores. If they are successfully verified, two tickets are generated, containing the PUID for this account and the time of the authentication.
One is saved as a cookie (MSPAuth) in the Passport domain and is encrypted with Passport's key.
The other is encrypted with Site1's key. It has to be initially transferred to Site1 via the querystring, because Passport servers don't have access to the Site1 domain. Site1 servers can then save it as a cookie (also MSPAuth) in the Site1 domain so that the user stays authenticated in subsequent requests. The server code can choose whether to trust this ticket based on the freshness of the timestamp.

Single sign-on:
Now that the user is logged into Site1, Passport's single sign-on feature allows him to get authenticated with Site2 without having to re-type his password.

When the user navigates to Site2, no ticket is stored in the Site2 domain, so he is not logged in.
The site can require the user to be authenticated, in which case it will redirect him to Passport. Or if logging in is optional, it will just display a sign-in image with a link and letting the user click on it.
When he is sent to Passport to get authenticated, the cookies in the Passport domain are used to generate a ticket for Site2. A redirect transfers it to Site2 via the querystring.

Passport Manager:
The Passport Manager COM object makes it easier for participating sites to implement their side of the Passport authentication. It helps manage crypto keys, read encrypted tickets, store them as cookies, generate login requests and display the sign-in image.
Its SDK documents additional parameters, like the return url or the time window during which a user is asked to have last authenticated.

Return URL:
Whenever an authentication is requested from Passport, the initiating site can choose where the user should be sent back, using the Return URL parameter (RU). When the site registers into the Passport network, it specifies his Root URL, against which any Return URLs will be validated to control were tickets are sent.
If no Return URL is specified, a Default Return URL configured for that site will be used instead.

Time window:
When Site2 sends the user to get authenticated, the sign-in request contains a TimeWindow querystring attribute.
If the cookies in the Passport domain state that the user hasn't authenticated within this time window, the user will be shown a login prompt instead of getting silently logged in.

Force login:
A ticket doesn't just contain the time that the user last was authenticated by typing his password. It also contains the time it was last refreshed.
Whenever a ticket for Site2 is generated using the Passport ticket, this timestamp gets updated.

As part of the authentication request, Site2 can request that the time window constraint be applied to either timestamp (last refresh and last manual sign-in), using the ForceLogin parameter.

Secure sign-in:
For additional security, a site can request that the authentication and tickets should occur over a secure channel, to limit the packet-sniffing risk.
In that case, the Return URL is required to be an SSL URL.

Also, a secure cookie (MSPSec) is set in both the Passport and the site domain. The browser makes sure this cookie is never exchanged over a non-secure link. Passport Manager can then check the presence and content of this cookie to confirm that the ticket wasn't stolen by sniffing the network.

Automatic sign-in:
We've seen that a site ticket can be re-generated as long as you have a Passport ticket within the time window that the site is requesting. There is another ticket in this chain of trust, the ticket-granting ticket (MSPSec).

It is stored as a secure cookie in the Passport domain and contains the information needed to silently log the user in over a long period of time.
This cookie is set permanently, when the user opts to automatically get logged-in on a specific machine, until the user signs out.

Visited sites and sign-out:
As the user logs into multiple sites, Passport keeps track of the list of visited sites in a cookie, MSPVis.
Each site participating in the network needs to declare a url for signing users out.

Whenever a user needs to be logged out of Passport, a page is built, referencing the logout url for each site that was visited by the user. This allows Passport to clear the cookies in all those domains.
If all logout urls loaded properly, the logout page refreshes itself to the Return URL.

SDK:
All of the information provided above can be found in publicly available documents (mostly the Passport SDK) or easily inferred from a network trace of an authentication exchange.
.NET Passport 2.5 Software Development Kit: Software and Documentation. The SDK documentation explains Passport in greater details (be sure to check out the VBScript part, which has the richest description, for some reason).
My description of the current Passport web protocol is provided with no warranties (about its accuracy or other) and definitely isn't meant to replace the SDK ;-)

Links:
The great Kerberos introduction text: "Designing an Authentication System: a Dialogue in Four Scenes".

Andre Durand (PingID) points to a survey on identity being hot amongst the 15 top-rated technologies.

My previous posts on introducing HTTP and thinking about authentication by URL.

The upcoming Typekey service from the MovableType team. (I'm curious to find out what their protocol looks like and will post more details when they become available)
Flickr authentication service.
SharedID authentication service.

This is so cool.
That's what I need for.
Thanks a lot~ :)

Hi :) Very nice information. I have unfortunately run into a brick wall when programming a passport login script (which is how i found your site) so i thought i was gonna ask you if you perhaps would have got a few minutes to answer a question? Drop me an e-mail and i'll explain the sutation to you :)

ummm r you dsaying how to get someones else's passport password?

Tommy, no :-)
Passport, as all authentication systems, is a trade-off between security and convenience. So the protocol has some known limitations: for example, cookies could be stolen by sniffing cleartext HTTP requests. But with those risks/choices in mind Passport seems pretty robust.
I don't know of any exploit/flaw that would allow to steal somebody's password without using a trojan/keylogger or looking over a person's shoulder.

Microsoft passport is great idea... But it's not popular now. I think the main problem of such systems is security holes.

Is there a proxie service or other method for signing on to my Hotmail account without enabling javascript on my computer? I am no able to access my account because I do not enable Java. I will not enable Java just to use MS services. Will I have to abandon my account, or is there another solution to prevent the "marketing_study/social_engineering" invasion of privacy?

Thank you.

Sarah, not that I know of.
If you are concerned about invasion of privacy, I suggest that you read MSN's privacy statement to make your decision to use these services (or not).
By definition, any form of authenticated service will allow tracking your activity, whether you use a proxy or not.