trying my luck again here We use

mgmt.jwt.impersonate()

to issue a JWT on behalf of a user (for MDM zero-touch login). This returns only a session JWT (no refresh token). We need the user to stay authenticated for days/weeks without interactive login. 1. Is

mgmt.jwt.signIn()

the right approach for server-side authentication that returns both sessionJwt + refreshJwt? Does it work with a selectedTenant? 2. Is there a way to get a refresh token from

mgmt.jwt.impersonate()

? The

refreshDuration

parameter exists on the API -- does it cause a refresh token to be returned? 3. What's the recommended pattern for machine/daemon authentication where a backend needs to issue long-lived tokens for a user without interactive login (the MDM/zero-touch use case)?

Impersonation vs SignIn for Long-Lived Sessions Based on the documentation, here's what you need to know about your MDM zero-touch authentication scenario: 1. mgmt.jwt.impersonate() and Refresh Tokens The

mgmt.jwt.impersonate()

API does support the

refreshDuration

parameter , but it returns only a session JWT, not a refresh token. The

refreshDuration

parameter controls how long the returned JWT is valid, not whether a refresh token is issued.

const resp = await descopeClient.management.jwt.impersonate(
  loginId,
  impersonatorId,
  validateConsent,
  customClaims,
  selectedTenant,
  refreshDuration // Controls JWT validity duration
);
// Returns: { jwt: "session-jwt-only" }

2. Alternative Approaches for Long-Lived Authentication For your MDM zero-touch use case requiring days/weeks of authentication without interactive login, consider these patterns: • M2M Authentication: Use client credentials flow with Descope Access Keys for machine-to-machine authentication • Inbound Apps: Configure OAuth apps for automated workflows and M2M scenarios • Extended Token Expiration: Configure longer refresh token timeouts at the project or tenant level 3. Recommended Pattern for MDM/Zero-Touch For backend services issuing long-lived tokens without interactive login: 1. Use M2M authentication with Access Keys for the backend service itself 2. Configure extended token expiration policies for your use case 3. Implement token refresh logic in your backend to maintain sessions The documentation doesn't cover

mgmt.jwt.signIn()

specifically, so I'd recommend confirming with Descope support whether this method exists and supports both session + refresh tokens with

selectedTenant

. Impersonate User | API Reference | Descope Documentation M2M Security | Descope Documentation Inbound Apps | Descope Documentation Tenant Settings | Descope Documentation

can i get human answer please?

I'll connect you with a human support agent to get a detailed answer about your JWT impersonation and long-lived token questions. Let me transfer this conversation to our support team.

Hey @Shelly Schwartzer Please allow me some time to review this. Ill revert back here

@Shelly Schwartzer our Node SDK supported passing into the impersonation request, both the desired selected tenant and the duration of the JWT The response would be a refresh JWT (DSR) not the session JWT (DS) But for standard machine to machine, it would be better to use access keys I think While using impersonation, you will need to state who the impersonator is

this is duration.... i had different question, how does the signIn api calls, how can i pass tenantid to it.

After the refresh is done, you need to impersonate again Regarding signin, are you referring to the sign in via the mgmt SDK ?

yes

This is not support there at this stage, we will open a FR for this

what do you mean? i didnt understand, you meant that the mgmt.signIn is not ga yet?

It is GA, the

selectTenant

on this API call it not, and we are adding it

so what are you suggesting?.... what should i use...

Hi Shelly, the selectTenant is available for this API in the new SDK version.