High Level explanation of how Windows Live ID works

If you are using a web application that uses Windows Live, such as Microsoft Dynamics CRM Live, you might be wondering, how does authentication work.

The first step in the process is that the web application registers with the Windows Live ID service. This registration includes creating unique keys for the application and storing a URL that the Live ID service will use to redirect users after they sign into Windows Live ID.
The 2nd step is when the application wants to authenticate the user. The application will provide the 'sign-in' link on it's web page. When clicking on the link, the user will be redirected to a sign-in page hosted by Windows Live ID. When this happens a token is also passed that identifies the application. By passing in a token that was given to the application at time of registration, the sign-in page understands who is calling it.
The 3rd step is that the user logins into Live ID. After logging into Live, the Live service redirects the user to the applications designated page that it registered with. The application can then redirect back to the original landing page the user came in on. Presto, you are authenticated to the Web application.

Windows Live does not store or pass any permissions ( or personal ) information to the application. It's the applications responsibility to manage the permissions. Windows Live is used to handle the authentication. Authentication is validating that the user is who the user claims they are. Below is a high level architectural diagram of the Windows Live ID Service.

For client side applications it's little different. On the client side, applications utilize a special component named MSIDCRL40.dll. This component handles a variety of services such as encryption. The client side application will need a to create or retrieve a key that is used. In a software+service model, this might include calling into a web service of a online application to retrieve a dynamically generated key that is used. After the call is made, a token is used that can be presented to the application that can be checked against the original key to ensure that the authentication was not compromised. After that the user is authenticated and again the application handles permissions internally. In both scenarios, the authentication is time stamped to be valid only for a specific time. The time stamped token can be  'cached' just like cookies are used in web application.