[WIP] Block direct sign-in flow initiation from browser SPAs

[Malith-19]

Purpose

Block browser SPAs from initiating a sign-in flow directly via POST /flow/execute, and require the redirect-based OAuth2 authorization_code + PKCE flow instead.

A browser SPA initiating a flow passes a public applicationId, which the server cannot use to authenticate the client. This is the SDK-side item of the secured-by-default model agreed in the design discussion. Since the SDKs have not had a release yet, this removes the capability rather than deprecating it. The config-time backend guard (a public-client SPA must use the authorization_code grant) is tracked separately under thunder-id/thunderid#3216.

Approach

• Hard block at the shared core: executeEmbeddedSignInFlowV2 throws a ThunderIDRuntimeError when a new sign-in flow is initiated (applicationId + flowType) in a browser context. @thunderid/browser, @thunderid/react, and @thunderid/vue all reach this function through the core, so a single guard covers every browser SPA SDK.
• Non-SPAs still work: the guard is keyed on the runtime environment (window/document). Server-side / confidential-client usage (e.g. @thunderid/express, which initiates this V2 flow server-side) runs in Node, so it may still initiate the flow. The hosted Gate UI is also unaffected — it only continues a redirect-initiated flow via executionId, never initiates.
• Scoped to sign-in only — deliberately. Thunder's /authorize handler initiates authentication only, so registration and recovery have no redirect-based equivalent and are left unchanged. The V1 executeEmbeddedSignInFlow targets /oauth2/authn (a legacy, non-Thunder endpoint) and is out of scope.
• Developer guidance: JSDoc on the react <SignIn> and vue SignIn components, plus a note in the JavaScript SDK README.

Note: client-side detection is an SDK-level fail-fast for honest developers, not a security boundary — the real enforcement is the backend guard (thunder-id/thunderid#3216).

Related Issues

• Refs Update SDK to remove native SPA flow patterns and redirect developers to authorization_code + PKCE flows thunderid#3217

Related PRs

• Docs (in thunderid repo): [Docs] Block direct sign-in flow initiation from browser SPAs thunderid#3455
• Backend config-time guard: Block SPA application creation with embedded flows and add backend validation to prevent native flow configuration thunderid#3216

Checklist

• Followed the contribution guidelines.
• Manual test round performed and verified.
• Documentation provided. (JSDoc + README; docs site updated in [Docs] Block direct sign-in flow initiation from browser SPAs thunderid#3455)
• Tests provided.
  • Unit Tests
  • Integration Tests
• Breaking changes. (Fill if applicable)
  • Breaking changes section filled.
  • breaking change label added.

---

⚠️ Breaking Changes

🔧 Summary of Breaking Changes

Browser SPAs can no longer initiate a sign-in flow directly via executeEmbeddedSignInFlowV2 (the embedded <SignIn /> component or useThunderID().signIn({ applicationId }) used standalone). Doing so now throws a ThunderIDRuntimeError.

💥 Impact

Browser SPA apps that drove sign-in with the app-native (embedded) flow. Server-side clients, and the hosted sign-in (Gate) continuation path, are not affected. The SDKs have not been released, so no published consumers are impacted.

🔄 Migration Guide

Configure the application for the authorization_code grant with a registered redirect_uri, and sign in via the redirect-based flow — for example @thunderid/browser's signIn() or @thunderid/react's <SignInButton />. See Register an application.

Security checks

• Followed secure coding standards in WSO2 Secure Coding Guidelines
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.

Note

[WIP] — opened for testing and fine-tuning before review.