Hi Descope team, I’m reaching out for some clarifi...
# ask-a-descoper
r
Hi Descope team, I’m reaching out for some clarification regarding a login integration use case we are currently working on. We have a third-party platform that uses Privy as its authentication provider. Our goal is that when a user is already authenticated on the third-party platform and is redirected to our application, they should be able to automatically sign in to our Descope-based application without having to log in again. After reviewing the documentation and available options in the console, it seems that Session Migration is the only feature that appears to support this kind of external token-based automatic login flow. However, in the Session Migration configuration, the available options I can currently see are only: • Auth0 • Okta • None As far as I understand, Privy is neither Auth0 nor Okta. I attempted to use the Session Migration approach by passing the Privy-issued JWT token through
getExternalToken
in the
AuthProvider
, but the authentication fails with the following error:
Copy code
{
  "errorCode": "E064201",
  "errorDescription": "Invalid external auth configuration"
}
At this point, I would like to clarify whether: 1. This use case is actually supported by Descope 2. Session Migration is indeed the correct approach for a Privy-based external identity provider 3. There is an additional configuration step required for custom providers such as Privy 4. Or whether this approach is fundamentally unsupported / not the intended use case In short, I would like to understand whether I am simply missing a configuration step, or whether this integration path is not currently feasible. Any guidance would be greatly appreciated. Best regards
a
@Roy Luo Session migration supports only Auth0 and Okta. The recommended approach is to verify the Privy-issued token on the backend and then use a Descope Flow to create/authenticate the user and establish a session.
r
Thank you. Is it okay to give me a bit more details about the flow? I am new to auth.
a
Sure Roy, the flow would look like this, 1. User logs in with Privy 2. Frontend gets the Privy token and sends it to your backend 3. Backend verifies that token (basically making sure it’s valid and really from Privy) 4. Once verified, backend tells Descope: “this user is legit, log them in” (using a Flow) 5. Descope creates/logs in the user and returns a session 6. Backend sends that session back to the frontend 7. Frontend uses that session and the user is logged in
r
Thanks 🙏 I think i had tried to use some kind of signin api at the backend, which returned tokens to the frontend. But it never managed to make the user log in from the frontend. Can you please confirm if it is completely different from what u just mentioned or I was at the right track but made some mistakes?
a
You are on the right track but one thing, backend needs to either set the descope session cookie in response, in which case the frontend will be automatically authenticated Or backend will return a session token, in which case the frontend needs to explicitly initialize the descope SDK session with the token. Please try this and if it still doesn't work, can you share which api you used on the backend and how you passed the token to the frontend?
r
Thank you very much! I will try it later today. 🙏