Interaction Prompt select_account

[Unknown-Robot]

Hi everyone,

I'm currently implementing a multi-account feature similar to Google's "Choose an account" flow, leveraging the select_account prompt within node-oidc-provider. The goal is to allow a user, potentially already logged in with Account A, to select Account B (for which they also have an active session on the same device/browser) and continue the OIDC flow seamlessly with Account B's context.

The Use Case & Challenge:

An interaction (uid) is initiated while Session A (jti_A) is active (via the _session cookie). The provider correctly stores a reference to this original session within the interaction object.

The policy includes a select_account prompt triggered by custom logic (detecting multiple sessions linked via a device cookie) or the third party explicitly requests the select_account prompt in the authentication request.

The user is directed to a custom UI (/select-account). In the UI, the user selects Account B.

My backend API (POST /api/select-account) identifies the target session for Account B (jti_B) and updates the _session cookie to jti_B.

This API then needs to call provider.interactionResult() to signal the select_account prompt is complete and let the provider determine the next prompt based on Session B's context (e.g., skip login/mfa, proceed to consent).

The interactionResult returns the resume URL (/auth/:uid).

When the browser navigates to GET /auth/:uid, the provider loads the interaction (which still references the original Session A's UID internally) but loads Session B (due to the updated cookie). This triggers the internal check originSession?.uid !== session.uid, resulting in a SessionNotFound error ("interaction session and authentication session mismatch").

Current Workaround (Considered Fragile):

The only way I've found to bypass this check is to manually manipulate the internal interaction.session object before calling interactionResult in my /api/select-account handler, forcing it to reference the details of Session B.

// Inside POST /api/select-account
const interaction = await provider.interactionDetails(req, res);

// The user has selected an account that is already authenticated in browser
if(accountId !== null) {
    const accountSession = await findSessionByAccountId(accountId);
    if(!accountSession) {
        throw(new Error("The account session doesn't exist"));
    }
    
    interaction.session = {
        accountId: accountId,
        cookie: accountSession.jti,
        uid: accountSession.uid,
        acr: accountSession.acr,
        amr: accountSession.amr
    };
    
    res.cookies.set(
        provider.cookieName('session'),
        accountSession.jti
    );
}
// The user has selected a new account
else {
    interaction.session = undefined;
    
    res.cookies.set(
        provider.cookieName('session'),
        null
    );
}

await interaction.persist();

const result = { selectAccount: { id: accountId } };

const redirectURL = await provider.interactionResult(req, res, result, {
    mergeWithLastSubmission: false
});

While this works, modifying internal library state feels risky and prone to breaking with future updates.

It would be beneficial to have an officially supported mechanism to handle this session switch cleanly during an interaction.

The Idea / Proposal:

A specific payload within interactionResult, could the result payload include an optional property like selectAccount that instructs the provider to gracefully handle the session change during the resume step, bypassing or adapting the originSession.uid !== session.uid check in this specific scenario ?

A dedicated method, perhaps a method like provider.setInteractionSession(uid, newSessionId) or interaction.switchSession(newSessionId) could be called before interactionResult to update the interaction's internal session reference in a controlled way ?

This would allow developers to build seamless multi-account experiences more reliably without resorting to potentially fragile workarounds.

I'd appreciate any thoughts on this, or if there's an existing best practice I might have missed for achieving this specific type of session switch within an ongoing interaction.

[panva]

I'd appreciate any thoughts on this, or if there's an existing best practice I might have missed for achieving this specific type of session switch within an ongoing interaction.

There isn't. I never considered multi-session to be in scope and as such there's no support for it. It might be you get to make it work but that's entirely accidental.