Skip to main content
This article describes how your service can generate User Store IDs directly, without exchanging access tokens and keys through the game client. This approach is useful for:
  • Experiences where there isn’t a game client within the flow
  • Linking the user’s XBOX account to your own service’s account for the user
  • Games and services that are already using XBOX Security Tokens (XSTS or X-tokens) authentication for client-to-service and service-to-service calls
For information on User Store IDs in general, see Requesting a User Store ID for service-to-service authentication.

X-token requirement

This process requires the use of a Delegated Auth X-Token to identify the user that the User Store ID represents. For more information on Delegated Auth X-Tokens and how to create them, see the “Title service calls to XBOX services” documentation.

OAuth 2.0 requirements to generate the User Store IDs

If your service uses OAuth to have the user sign in with their Microsoft Account (MSA), the following are required:
  • User must have an XBOX identity tied to their Microsoft Account as the OAuth credentials need to be exchanged for an X-token.
  • The OAuth scope you request must include both xboxlive.signin and xboxlive.offline_access to ensure proper user consent for this flow and ability to retrieve the required X-token.
For more information on using XBOX services sign-in with OAuth on your service, see the “XBOX services sign-in for title websites” documentation.

Steps when using OAuth 2.0 credentials

With OAuth, you obtain user consent and exchange OAuth credentials for an X-token against your relying party. After that, continue with the same flow in Steps when using X-Tokens. Outline flow to exchange OAuth credentials for an X-token:
  1. Obtain the OAuth 2.0 authorization code
  2. Exchange the authorization code for an RPS token (also called a Microsoft Account access token)
  3. Exchange the RPS token for an XBOX User Token
  4. Exchange the XBOX User Token for an X-Token against your own Relying Party
  5. Use the X-token in Steps when using X-Tokens.
For full implementation details, see the “XBOX services sign-in for title websites” documentation.

Steps when using X-Tokens

After you have an X-token that identifies the user for your relying party, use its DelegationToken claim to create a Delegated Auth X-token. The initial X-token can come from either the game client or the OAuth 2.0 flow. Outline flow to create a Delegated Auth X-token:
  1. Extract the DelegationToken claim (dlt) from the user’s X-token.
  2. Obtain a Service Token from the XSAS service using your Business Partner certificate.
  3. Exchange the DelegationToken, Service Token, and target Relying Party (see table) for a Delegated Auth X-token.
For full implementation details on how to create Delegated Auth X-tokens, see the “Title service calls to XBOX services” documentation. In step 3, the Relying Party that you use depends on if you’re generating a User Collections ID or a User Purchase ID for the user:

Request

Once you have the Delegated Auth X-token, request the User Store ID using the corresponding URI for the service you’re calling.

Request syntax

Request header

Request body

Request example

Response

Response body

Response example

See also

Manage products from your services Authenticating your service with the Microsoft Store APIs Title service calls to XBOX services XBOX services sign-in for title websites Renewing a User Store ID key Microsoft.StoreServices library Microsoft.StoreServices sample
Last modified on August 20, 2026