How to Configure Windows Sandbox Local Dex OIDC Identity Provider via XML in Windows 11

Modern microservice architectures and Kubernetes platforms rely on OpenID Connect (OIDC) to federate authentication across enterprise directories (such as LDAP, SAML, and GitHub). Testing OIDC token issuance, JWKS key rotation, and OAuth2 callback flows directly on a developer workstation can cause certificate conflicts and background service clutter. In Windows 11, Windows Sandbox provides a pristine, isolated testing platform. By authoring custom Windows Sandbox XML (.wsb) configuration files, you can deploy a standalone Dex OIDC identity provider in seconds.

Architecture of the Disposable Dex Sandbox

Windows Sandbox provides a disposable, hypervisor-isolated guest environment that resets completely upon termination. To provision an automated Dex instance, the architecture requires:

• A mapped host folder: A directory containing the standalone dex.exe binary and a minimal configuration YAML file.
• A WSB configuration file: An XML blueprint that mounts the mapped directory and initiates the identity provider automatically via LogonCommand.

Authoring the Windows Sandbox WSB Blueprint

Create a working directory on your host machine, such as C:\SandboxDex. Download the Windows binary of Dex into this directory, then create RunDex.wsb with the following XML code:

<Configuration>
  <VGpu>Default</VGpu>
  <Networking>Default</Networking>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxDex</HostFolder>
      <SandboxFolder>C:\DexFiles</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>powershell.exe -ExecutionPolicy Bypass -NoExit -File C:\DexFiles\Start-Dex.ps1</Command>
  </LogonCommand>
</Configuration>

Authoring Dex Configuration and Startup Script

Inside the mapped host folder (C:\SandboxDex), create a Dex configuration file named config.yaml:

issuer: http://127.0.0.1:5556/dex

storage:
  type: memory

web:
  http: 0.0.0.0:5556

staticClients:
  - id: example-app
    redirectURIs:
      - 'http://127.0.0.1:8080/callback'
    name: 'Example App'
    secret: ZXhhbXBsZS1hcHAtc2VjcmV0

enablePasswordDB: true

staticPasswords:
  - email: "[email protected]"
    hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"
    username: "admin"
    userID: "08a16b83-de0b-4241-a6b0-b4e8744e1e69"

Next, create the automated PowerShell initialization script named Start-Dex.ps1:

Write-Host "=============================================" -ForegroundColor Cyan
Write-Host " Starting Dex OIDC Identity Provider in SB.. " -ForegroundColor Green
Write-Host " Issuer URL:  http://127.0.0.1:5556/dex       " -ForegroundColor Yellow
Write-Host " Discovery:   http://127.0.0.1:5556/dex/.well-known/openid-configuration " -ForegroundColor Yellow
Write-Host " Test User:   [email protected] (password: password) " -ForegroundColor Yellow
Write-Host "=============================================" -ForegroundColor Cyan

# Launch Dex identity provider
& "C:\DexFiles\dex.exe" serve "C:\DexFiles\config.yaml"

Running and Validating OIDC in the Sandbox

Double-click RunDex.wsb on your Windows 11 host. Windows Sandbox boots up, mounts the mapped folder, and immediately launches Dex inside an interactive PowerShell window.

Dex begins listening on port 5556. Open Microsoft Edge inside the sandbox and navigate to http://127.0.0.1:5556/dex/.well-known/openid-configuration to inspect the OIDC discovery document and JWKS signing keys.

You can execute OAuth2 authorization code grants, inspect ID token claims, and test single sign-on flows in complete isolation. When testing concludes, closing the sandbox window instantly eliminates all memory datastores, private signing keys, and server processes, leaving your host workstation completely clean and unburdened.