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 Sign-In for Long-Lived Sessions The

mgmt.jwt.impersonate()

method returns only a session JWT by design . The

refreshDuration

parameter sets the JWT validity period but doesn't generate a refresh token . For your MDM zero-touch use case requiring days/weeks of authentication, consider these approaches: Option 1: Use M2M Authentication

// Client credentials flow for machine authentication
const response = await fetch('<https://api.descope.com/oauth2/v1/token>', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'client_credentials',
    client_id: 'your-access-key-id',
    client_secret: 'your-access-key-secret'
  })
});

This returns both access and refresh tokens for machine-to-machine scenarios . Option 2: Extend Impersonation Duration

// Set longer refreshDuration for impersonation JWT
const resp = await descopeClient.management.jwt.impersonate(
  loginId,
  impersonatorId,
  false, // validateConsent
  customClaims,
  selectedTenant,
  2592000 // 30 days in seconds
);

Recommended Pattern for MDM/Zero-Touch For backend services issuing long-lived tokens without interactive login, use Descope Access Keys with client credentials flow . This provides proper refresh token support and is designed for automated processes . The

mgmt.jwt.signIn()

method isn't documented in the available resources, suggesting it may not be the standard approach for server-side authentication. Impersonate User | API Reference | Descope Documentation M2M Security | Descope Documentation Inbound Apps | Descope Documentation

Hi @Shelly Schwartzer , Yes you should use mgmt.jwt.signIn() to create the session and refresh token for your users. Impersonate is typically used when one user needs to impersonate another, but in this case your backend is simply signing the user without the user interacting with it, and therefore you don’t need to impersonate anything necessarily. As far as the refresh duration being part of the impersonate API request schema, I’m not sure and will have to check with the team on that. Using the signIn management function should accomplish your use case quite well.

I need to verify what

MgmtLoginOptions

accepts — specifically whether it has a

selectedTenant

field so the JWT is scoped to the right tenant?

It should allow you set the tenant I believe, but lmk if not.

selectTenant is a seperate request. the signIn is project wise, not tenant wise

@Bhagwanta Yeole can you help here ?

Hey @Shelly Schwartzer , I'm looking into this, will update you ASAP.

@Bhagwanta Yeole?

I'm looking for this with the dev team, will update you once get the resolution on this.

@Shelly Schwartzer is the user in one tenant or more than one tenant? If one tenant - use JWT templates and set to set the active tenant claim automatically

this seems not related to my question