Login/signup flow via xsts token (xboxlive relying party)

I have a question about how to integrate xboxlive single-sign-on with auth0.
The backend will receive a login request from the client containing an xsts-token from xboxlive that the backend can verify.
At this point we have a validated user, how do we proceed to provide the client with a jwt from auth0?
Is there a way for the backend to create an authorisation token or similar that the client can use when calling the /oauth/token endpoint?
Note that the user is already “logged in” so I dont want to trigger the universal login flow. And if the user does not exist yet, I want it to be “lazily” created (from the user’s perspective).

Thanks / Jonas

Hi @luckyswede,

Welcome to the Auth0 Community!

Usually, Auth0 will sit in the middle of the transaction and handle the auth request and token exchanges between the identity provider (xboxlive, in this case) and the application.

Do you know, does xbox live provide use a standard protocol like OAuth2?

Hi @dan.woda, thanks for your response :slight_smile:

As far as I know xbox does not support oauth2.

As a partner with xbox live, a title (game) that is launched on the console will get access to a token (an encrypted jwt) that represents the user that is logged in to the console, and can be used for single-sign-on to a game specific backend.
This token is encrypted with the title’s public key and signed with xbox private key. When the token is sent to a backend from the game, the backend is able to decrypt and verify the token.
After that process the user is authenticated in the backend, but since we want to use Auth0 for authentication we need to either create a jwt using Auth0 backend api’s, or return something else that the console game can exchange for a jwt using the Auth0 api’s.

One option would be for us to generate the jwt’s ourselves. In that case we could return a jwt directly in this case, and in the “normal” flow where a non-console client login via Auth0 we could exchange an Auth0 jwt for our own jwt.
But we would like to avoid that if possible.

Thanks / Jonas