OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.

kedar giri 106 Reputation points
2026-05-05T08:07:00.5+00:00

I have deployed an Azure Virtual Desktop** (AVD)** environment and assigned the user ******@shotmail.onmicrosoft.com with the following configurations:

Configuration Details:

User: ******@shotmail.onmicrosoft.com

  • Assigned in:
    • Application Group (AVD)
    • Host Pool → Session Host
  • IAM (Resource Group level):
    • Assigned roles:
      • Virtual Machine Administrator Login
      • Reader
  • No Conditional Access policies are applied across the tenant. Issue: When attempting to access the virtual desktop:
    • Using Windows App or
    • Via browser The Entra ID user receives a sign-in/access error User's image
      • Login using the local administrator account on the session host works without any issues.
      Observed Behavior:
      • AVD session connection fails only for Entra ID user
      • Local admin bypasses the issue
      Troubleshooting Done:
      • Verified role assignments and scope
      • Confirmed user is assigned to Application Group
      • Confirmed no Conditional Access blocking
      • Checked MFA configuration
      • Verified AADLoginForWindows extension is deployed on VM
        • Login using the local administrator account on the session host works without any issues.
      These are the step i have taken, to create vdi, am i missing something or require any additional step. any solution to this is appreciated thank you in advance
Windows for business | Windows Client for IT Pros | User experience | Authentication with Azure Virtual Desktop
0 comments
Answer accepted by question author
HLBui 11,095 Reputation points Independent Advisor
2026-05-05T09:10:33.9933333+00:00

From what you’ve described i think the core issue is that your Entra ID user is hitting an AADSTS54005 error, which means the authorization code they’re trying to use has already been redeemed. That’s why the local admin login works fine (it bypasses Entra ID altogether), but the AVD session fails for the cloud identity.

A few things you might double‑checking :

  1. User assignment in AVD Make sure the user is not only in the Application Group but also explicitly assigned to the Desktop Application Group (not just RemoteApp). Sometimes folks miss that distinction.
  2. RBAC vs. AVD permissions The “Virtual Machine Administrator Login” and “Reader” roles at the resource group level don’t actually grant AVD connection rights. The critical piece is the AVD app group assignment.
  3. Refresh token / session cleanup Since the error is about a redeemed code, have the user sign out completely from the Windows App/browser, clear cached credentials, and retry. In some cases, revoking sessions in Entra ID (via the admin portal) helps.
  4. Check the AADLoginForWindows extension You mentioned it’s deployed, which is good. Just confirm it’s in a healthy state on the VM.
  5. Licensing Ensure the user has the right license (like Microsoft 365 E3/E5 or equivalent with AVD rights). Without it, even correct assignments won’t let them in.
  6. Network / DNS Less common, but if the VM can’t reach Entra ID endpoints properly, you’ll see odd auth errors. Worth confirming outbound connectivity.

If this clears things up for you, please hit “Accept Answer” so others know the solution works. And if it's not, let me know we can dig into logs and session host configs.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-05T08:07:28.48+00:00

    The error AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token occurs during the Microsoft Entra ID token issuance step for the Azure Virtual Desktop client, not inside the VM itself. It indicates a problem in the sign‑in/token flow for that user rather than with the AVD host configuration.

    From the provided context, the closest documented guidance for similar token‑issuance errors is the AADSTS50000 article, which highlights that such errors are typically caused by issues with the user account, token request parameters, or consent.

    Based on that guidance, apply these checks for the affected Entra ID user and the AVD client app:

    1. Verify the user account and password
      • Ensure the user’s password is valid and not expired.
      • If the account is synchronized from on‑premises Active Directory, reset the password and confirm that the user can sign in successfully to other Microsoft Entra–protected apps (for example, the Azure portal or Outlook on the web).
      • This aligns with the documented guidance that expired/invalid passwords or revoked sessions can cause token issuance failures.
    2. Clear cached tokens and retry with a fresh sign‑in
      • On the client device, sign out of the Windows App / browser session completely.
      • Clear browser cookies and site data for login.microsoftonline.com and aad.portal.azure.com.
      • Close and reopen the AVD client or browser and initiate a new sign‑in so that a new authorization code is generated and redeemed only once.
    3. Check for session or consent issues for the AVD application
      • In the Microsoft Entra admin center, under Enterprise applications, locate the Azure Virtual Desktop–related service principals.
      • Confirm that the user is allowed to sign in and that no policy is blocking user consent or access for that app.
      • The AADSTS50000 guidance recommends verifying that the client application (service principal) exists and that user consent is allowed when token issuance errors occur.
    4. Revoke existing sessions and force a clean token flow
      • If the problem persists only for this user, revoke their existing sign‑in sessions so that all refresh tokens are invalidated and a completely new authorization flow is required.
      • This addresses scenarios where a previous session or token state is causing repeated failures.
    5. Validate that VM‑side Entra sign‑in prerequisites are met (already mostly done)
      • The user has Virtual Machine Administrator Login at the resource group scope, which satisfies the documented requirement that a VM‑sign‑in role be assigned.
      • AADLoginForWindows is installed and local admin sign‑in works, which matches the documented prerequisite that the extension must be successfully deployed.
      • No per‑user MFA is enforced and no Conditional Access policies are blocking sign‑in, which aligns with the guidance that VM sign‑ins do not support per‑user enabled/enforced MFA.

    If, after resetting the password, clearing cached tokens, and revoking sessions, the user can sign in to other Entra‑protected apps but still cannot obtain a token for AVD, collect the full error details (request ID, correlation ID, timestamp) from the error page and open a support case so that the token acquisition request for the AVD client can be reviewed in the Entra sign‑in logs.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.