Windows Live ID Delegated Authentication SDK for Application Providers

This topic describes functionality that will be obsolete. This functionality is provided only to support legacy applications. Live Connect incorporates features that provide equivalent functionality.

Windows Live™ provides a wide variety of Web services and sites, but we recognize that it can't provide every Web service needed by every user. Many sites like yours—which we call application providers—want to help expand Windows Live by creating an even greater variety of Web services and sites. These application providers also want to take advantage of Windows Live ID authentication to prove to Windows Live services that a trusted relationship exists between the user and their sites.

With Windows Live ID Delegated Authentication version 1.2, you can develop an application that acts on behalf of a Windows Live ID user to access Web services and sites that use Windows Live ID authentication. There are millions of registered Windows Live ID users, and you can create applications that offer them personalized access to their content on other Windows Live services and sites.

Included with this software development kit (SDK) are sample applications that implement Delegated Authentication in the C#, Visual Basic® .NET, Java, Perl, PHP, Python, and Ruby programming languages. You can get the sample applications for this SDK from the Delegated Authentication download page on

Delegated Authentication works by sending your users to the Windows Live ID consent page, where they can grant or deny permission for your site to access their data or content on Windows Live services (called resource providers in the Delegated Authentication context). Resource providers register offers and actions with the Windows Live ID service, and it is these offers and actions to which users grant consent. After a Windows Live ID user has granted your site consent to a given set of offers and actions, your site can then interact with the resource provider on behalf of that user.

Sign-in and consent management functions are performed by the Windows Live ID service, so you don't have to worry about implementing these details. Also, with Delegated Authentication, you have access only to information for which a user has expressly given consent. This means that you do not have to extend your application to help safeguard user information that is not relevant to your site. As a result, you can focus more on the functionality of your application and less on managing user data.

It's easy to start using Delegated Authentication on your site. The following steps outline the general tasks involved in implementing Delegated Authentication:

  1. Register your application. Registering is a critical step to implementing Delegated Authentication. By registering your application, your site can interact with Windows Live services in general, and can receive consent from users to access their information on their behalf. For more information about registration, see Getting Your Client ID for Delegated Authentication.
  2. Install and run the sample application for your platform. For details, see Samples for Delegated Authentication.
  3. Implement resource-provider functionality. Each resource provider presents a different set of offers and actions, so you must first obtain information about those offers and actions from the resource provider with which you want to work. For more information about available resource providers, see the Resource Provider Directory on the Windows Live Dev Web site.
  4. Request consent from the Windows Live ID user and receive a consent token from Windows Live ID. For details, see Requesting Consent.
  5. Store the consent token for use with the resource provider. For details, see Working with Consent Tokens.
  6. Parse the consent token to obtain the delegation token. For details, see Working with Delegation Tokens.
  7. Use the delegation token to access an allowed offer and action. To do this, you invoke the offer and action from the resource provider and provide the delegation token as proof of the user's consent. For more information, see Working with Offers and Actions.
  8. Display or store content or personalized data obtained from the resource provider on behalf of your user, in accordance with your site's security policies.

The core tenet of Delegated Authentication is that users own their own data. They can decide which sites get access to that data and what those sites can do on the user's behalf with that data. This principle places certain responsibilities on the application provider. Your site should:

  • Handle the user’s data in accordance with your site’s privacy policy. The data still belongs to the user after the resource provider releases it to your site.
  • Use the delegation control information—tokens, identifiers and other system data that you receive from the Windows Live ID service—only at the site we send it to. This information is sent to a single application and should not be shared.
  • Use the delegation control information for a particular user to obtain access only to that user’s data. This information is specific to the user and to the resource providers that store the user's data.

Ready to begin? Move on to Getting Started with Delegated Authentication.

Other Resources

Live Connect