Architectural Overview of Delegated Authentication

Before we get into the details of implementing Delegated Authentication on your site, let's take a moment to understand the overall flow of events involved in the consent process.

A Windows Live ID user consents to Delegated Authentication and controls the amount of information available to your site from the resource provider that your site is attempting to access. Consent information is stored by Windows Live ID, and the user can manage this information at any time by using the Windows Live ID consent service. Your site receives a consent token, which contains information about the offers and actions to which the user has granted or denied consent, and a delegation token for use with the resource provider. For details, see Consent Tokens.

Consent Flow

The following figure illustrates the relationships between the user, your Web site (as an application provider), a resource provider, and the Windows Live ID service when your site requests consent.

Cc287682.c5c3dc05-4441-44e7-b9f5-c39117464259(en-us,MSDN.10).bmp

The stages of consent, as shown in the figure, are:

  1. The user requests a Web page that requires delegated authentication. The user, by means of a Web browser, visits your Web site for the first time and has not yet signed in by using Windows Live ID. Your Web site is designed to use a resource from a resource provider (typically a Windows Live service) that requires Delegated Authentication.
  2. Your site redirects the user to the Windows Live consent-request page to request consent. Your site provides its application ID, return URL, and the names of the offers and actions requested, as part of the URL to which your user is redirected. For details, see Requesting Consent.
  3. Windows Live ID retrieves offer information for the resource provider. The resource provider has defined offers and actions in advance when registering with Windows Live ID. Windows Live ID stores these definitions and retrieves them during the request process, comparing them against the offers and actions specified in your request.
  4. Windows Live ID verifies any existing consent for offers and actions. The user may have previously granted consent for you to use some of the offers and actions specified in your request. The Windows Live ID service therefore checks the offers and actions you requested against any existing consent information for those offers and actions before presenting the user with information.
  5. Windows Live ID retrieves external offers and granular permissions for the resource provider. The resource provider can create dynamically defined (or external) offers and actions to be retrieved at the time consent is requested, and can optionally provide a Web page for more specific, granular permissions for its offers. For more information about offers and granular permissions, see Offers and Actions.
    Cc287682.note(en-us,MSDN.10).gifNote:
    The details of particular offers, actions, and granular permissions are defined by the resource provider and are not in the scope of this documentation. For more information about offers, actions, and granular permissions offered by a specific resource provider, see the documentation provided by that resource provider. You can see a list of available resource providers on the Resource Provider Directory.
  6. Windows Live ID displays the consent-request page. The Windows Live ID consent service directs the user to its consent-request page. If the user is not yet signed in to Windows Live ID, he or she is prompted to do so. The consent-request page lists the offers and actions to which the user can grant or deny consent, as well as descriptions and, if available, granular permissions for each offer and action.
  7. The user grants or denies consent. On the Windows Live ID consent-request page, the user grants or denies consent for the offers, actions, and granular permissions provided by the resource provider, and then submits the page to the Windows Live ID service.
  8. Consent information is stored by Windows Live ID. Windows Live ID stores in its database the information that represents the user's consent to your site's access to the resource provider's resources.
  9. The Resource Provider verifies and stores granular permissions. Because granular permissions are managed by the resource provider, the Windows Live ID service sends that particular information to the resource provider for verification and storage. The resource provider can optionally include such information in the consent token received by your Web site at the end of the consent process. For more information about granular permissions, see Requesting Consent.
  10. Windows Live ID returns consent information to your Web site. After consent information has been provided by the user, the Windows Live ID consent server responds by redirecting the user to the return URL specified in your consent request. At the same time, Windows Live ID returns a consent token as a FORM POST parameter. The consent token contains a delegation token, a refresh token, expiration information, and a list of available offers and actions to which the user has consented. Your Web site should store the consent token in a protected location for future use.
Usage Flow

Now that your Web site has obtained consent from the Windows Live ID user, it can use the offers and actions from the resource provider on behalf of the user.

The following figure illustrates the relationships between the user, your Web site (as an application provider), a resource provider, and Windows Live ID when you invoke an offer and action from a resource provider.

Cc287682.1daf9c04-7efd-4ad7-aed7-fde5e2315cdc(en-us,MSDN.10).bmp

The stages of usage, as shown in the figure, are:

  1. Your Web site stores the consent token. The consent token contains the information required by your Web site to interact with the resource provider on behalf of the Windows Live ID user. You should store this consent token in a protected location for future use, because consent tokens may not expire for some time and can be reused. A new consent token is not necessarily required for each interaction with a resource provider, depending on the requirements of the resource provider and the preferences of the Windows Live ID user. For more information about consent token expiration, see Consent Tokens.
  2. Your Web site parses the consent token. The consent token contains the offers and actions to which the Windows Live ID user has consented, as well as the delegation token representing that consent. Your Web site parses the consent token to determine what, if any, offers and actions your Web site is permitted to perform on behalf of the Windows Live ID user, and then it parses the delegation token from the consent token to authorize the invocation of those offers and actions. Your Web site can also determine whether the delegation token has expired and, if so, attempt to refresh the consent token before performing any further steps.
    Cc287682.note(en-us,MSDN.10).gifNote:
    If the delegation token has expired, even if the offers and actions included in the consent token have not yet expired, your Web site must first refresh the consent token before invoking those offers and actions. Step 7 of the usage flow describes the refresh process in more detail.
  3. Your Web site invokes an offer and action from the resource provider. Your Web site calls the resource provider, passing the delegation token as authorization. The method of invocation is indicated by the offer and action returned in the consent token, and may vary depending on the implementation of the resource provider.
    Cc287682.note(en-us,MSDN.10).gifNote:
    The details of particular offers, actions, and granular permissions are defined by the resource provider and are not in the scope of this documentation. For more information about offers, actions, and granular permissions offered by a specific resource provider, see the documentation provided by that resource provider. You can see a list of available resource providers on the resource provider page.
  4. The resource provider validates the delegation token. The resource provider validates the delegation token with the Windows Live ID service, ensuring that the token hasn't expired, that it applies to the specified Windows Live ID user, and that it authorizes the offer and action being invoked.
  5. The resource provider validates granular permissions. Resource providers may store additional granular permissions as part of the offer and action requested by your Web site.
  6. The resource provider provides a response to your Web site. If the Windows Live ID service successfully validates the delegation token, the resource provider performs the requested offer and action and returns the resulting information to your Web site. If Windows Live ID fails to validate the delegation token—for example, if it determines that the delegation token has expired—the resource provider returns error information to your Web site.
  7. Your Web site refreshes the consent token with Windows Live ID. If a consent token has expired, your Web site can request that the consent token be refreshed by Windows Live ID. If the refresh is successful, Windows Live ID returns an updated consent token for use on behalf of the Windows Live ID user. Your Web site can then repeat steps 1 through 5 of the usage flow, using the updated consent token. For more information about refreshing consent tokens, see Refreshing Consent.
  8. Your Web site provides information to or performs an action for the user. Your Web site, having successfully retrieved information or performed an action for the user, presents the results to the Windows Live ID user.
See Also

Concepts

Consent Tokens
Delegation Tokens
Refresh Tokens
Offers and Actions

Page view tracker