Customizing the Subject in device flow authorization

[Bra1nFartz]

Hey folks,

We've hit a scenario where the user approving a device flow is not the intended subject of the resulting tokens — think delegated
authorization, kiosk provisioning, or an administrator approving a device on behalf of another user.

Currently our workaround is replicating the DefaultDeviceFlowInteractionService, but it's fragile — if the internal implementation changes (new fields, consent tracking, etc.), our code won't pick it up.

Is there a recommended way to handle this that we're missing? If not, would there be interest in an extension point — e.g., an overload that accepts a ClaimsPrincipal, or making the subject resolution virtual/overridable?

Happy to contribute a PR if there's appetite for it.

[wcabus]

What parts of the DefaultDeviceFlowInteractionService did you customize? Perhaps it is sufficient to subclass this service class and inject a custom IUserSession service instead to retrieve the correct ClaimsPrincipal.

[Bra1nFartz]

We could do that, but it could end up quite hacky, as there is no session per se. We create the claims principal from the user that needs to be authorized on the device that starts the device flow.

[wcabus]

Then perhaps the logic needs to be turned around a bit.

When the device initiates the flow by showing the QR code (or URI and user code to enter), a user who's setting up the kiosk or the admin in your use cases will navigate to the device page and first authenticate themselves.

Our template UI will then show a consent screen, where the authenticated user needs to confirm the granted consent for the device before the flow completes:

In your scenario, before granting consent, you would rather first perform an impersonation event to switch to the target user before granting consent. That way, the current subject or ClaimsPrincipal already points to the intended user before handing off the request to the IDeviceFlowInteractionService again.

This impersonation could be part of the device flow UI, automatically switching back after handling the interaction to the correct user.

sequenceDiagram
    actor User

    Kiosk->>+IdentityServer: /connect/deviceauthorization
    IdentityServer->>-Kiosk: { device_code, user_code, verification_uri, ... }
    Kiosk-)User: Display verification_uri and user_code
    User->>+IdentityServer: /verification_uri?userCode=user_code
    IdentityServer->>User: consent?
    User->>IdentityServer: consent!
    IdentityServer->>+IdentityServer: impersonate target_user
    IdentityServer-)+DeviceFlowInteractionService: HandleRequestAsync()
    DeviceFlowInteractionService-->>-IdentityServer: response
    IdentityServer->>-IdentityServer: end impersonation session
    IdentityServer-->>-User: Device authorized
    Kiosk->>+IdentityServer: /connect/token
    IdentityServer-->-Kiosk: { access_token, refresh_token }

Loading

Unfortunately, we can't dive into specific implementation details here, as that would exceed the scope of support. If you're seeking specific guidance, we can connect you to one of our partners to help with this on a consultancy basis. Feel free to contact us for more information.