Hello everyone,
Our use case requires that users who register via social connections must also ‘set a password’ (in our SPA UI) immediately following registration so that they always have credentials (even if primarily logging in with social). the reason for this is because, for product reasons, our users must always have the ability to change their email address on the platform. with auth0, for social-only registrations, this is not possible (unless we decide to denormalize the email and store it in our own database, which feels messy).
I’d also add that we’re using the BFF pattern. our API gateway is the auth0 client; as opposed to our SPA. our SPA communicates with the BFF only (and has its own session cookie independent of auth0’s).
Our flow looks something like this:
- User navigates to our SPA, is redirected to universal login through our BFF (express-openid-connect)
- User clicks ‘sign up’ and chooses Google
- User signs in through Google, gives consent, and redirected back to our BFF
- BFF creates a cookie with the Google identity’s access token and ID token
- User is redirected back to our SPA with a session, prompted to ‘set a password’
- Upon submission, the backend creates a second identity (username and password), and links the previous account to this one (so that the email address can be freely updated even if the existing social connections use the previous)
- After the accounts are merged, users are able to carry on using the platform, with the new identity (username/password connection) being the primary, due to the manner in which the merging was conducted
problem: the user’s current access token, in the existing cookie, is scoped to the original Google identity, and not the Username/Password identity that was created and made primary after-the-fact.
Forcing the user to log in a second time after the linking operation, strictly to get a new token, is out of the question from a UX perspective.
How can I reconcile them? Resource Owner Password Flow from the BFF (at the time where the password is in memory) to get a new access token, then manually create a new session cookie outside of the scope of the express-oidc middleware? On the next login, the middleware will do its job as expected given the merged identities.