fix(oauth2): persist linkAccountData during auto-link 2FA flow

[afahey03]

Fixes HTTP 500 when OIDC auto account linking (ACCOUNT_LINKING=auto) requires local 2FA. oauth2LinkAccount set linkAccount in the session before redirecting to 2FA but did not persist linkAccountData, so TwoFactorPost failed with not in LinkAccount session. The manual linking flow already stored both, this aligns auto-link with that behavior.

Created the test, TestOAuth2AutoLinkWithTwoFactor, which verifies that automatic account linking completes after the user passes local 2FA when an OIDC identity matches an existing account.

DISCLAIMER: I used AI to create the test

Closes #38171

[Copilot]

Pull request overview

This PR fixes a session persistence bug in the OAuth2/OIDC automatic account-linking flow when the target local user must pass local 2FA/WebAuthn. It ensures the account-linking context (linkAccountData) survives the redirect into the 2FA flow, matching the already-working manual linking behavior, and adds an integration test to prevent regressions.

Changes:

• Persist linkAccountData into the session when redirecting to the local 2FA/WebAuthn flow during OAuth2 auto-linking.
• Add an integration test covering OIDC auto account linking when the existing user has local TOTP 2FA enabled.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
tests/integration/auth_oauth2_test.go	Adds TestOAuth2AutoLinkWithTwoFactor to validate auto-link completes after local 2FA.
routers/web/auth/linkaccount.go	Stores linkAccountData in session for the auto-link + 2FA redirect path to avoid “not in LinkAccount session”.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[afahey03]

@bircni Thanks for your changes, do you mind taking one final look?

[bircni]

its better to let @wxiaoguang check again if its ok now

[wxiaoguang]

It should use 3e9078f , but not make a function do more things than it should do.

If anything wrong caused by it, there must be some bugs which need to be fixed.

[wxiaoguang]

If anything wrong caused by it, there must be some bugs which need to be fixed.

Indeed, bad design caused problems. Always fix existing bad designs, but not keep introducing more bad designs.

[afahey03]

@wxiaoguang

3e9078f split session persistence into two calls, Oauth2SetLinkAccountData (which calls updateSession/RegenerateSession once for linkAccountData) and then a second updateSession for twofaUid, twofaRemember, and linkAccount)

Each updateSession regenerated the session, but the second regeneration didn't carry linkAccountData into the cookie that the client received, so after 2FA the sesson didn't have linkAccountData`, which was effectively re-causing 500 bug that the PR was fixing

[wxiaoguang]

@wxiaoguang

3e9078f split session persistence into two calls, Oauth2SetLinkAccountData (which calls updateSession/RegenerateSession once for linkAccountData) and then a second updateSession for twofaUid, twofaRemember, and linkAccount)

Each updateSession regenerated the session, but the second regeneration didn't carry linkAccountData into the cookie that the client received, so after 2FA the sesson didn't have linkAccountData`, which was effectively re-causing 500 bug that the PR was fixing

See my commit and comment.

[afahey03]

@wxiaoguang
3e9078f split session persistence into two calls, Oauth2SetLinkAccountData (which calls updateSession/RegenerateSession once for linkAccountData) and then a second updateSession for twofaUid, twofaRemember, and linkAccount)
Each updateSession regenerated the session, but the second regeneration didn't carry linkAccountData into the cookie that the client received, so after 2FA the sesson didn't have linkAccountData`, which was effectively re-causing 500 bug that the PR was fixing

See my commit and comment.

Looks good, thank you