4 Commits

Author	SHA1	Message	Date
Konstantin Wohlwend	c8b516833e	Add requires_totp_mfa to JWT	2026-03-02 10:09:47 -08:00
Konsti Wohlwend	8052a2be62	"Require publishable client key" toggle (#1158) ... <!-- Make sure you've read the CONTRIBUTING.md guidelines: https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md --> <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **High Risk** > Touches authentication and OAuth token/authorize flows and changes how client requests are validated, so regressions could cause widespread login/client-access failures. Also includes a data migration that alters effective security posture for existing projects. > > **Overview** > Adds a **project-level toggle** (`project.requirePublishableClientKey`) to control whether client requests/OAuth flows must include a publishable client key, including a DB migration that backfills existing projects to require it. > > Backend auth now treats the publishable client key as *optional when allowed*, introducing a public sentinel (`__stack_public_client__`) and returning a new specific error (`PUBLISHABLE_CLIENT_KEY_REQUIRED_FOR_PROJECT`) across smart request auth + OAuth `authorize`/`callback`/`token` endpoints. > > Dashboard and SDKs update key generation/display and request construction to handle missing publishable keys, expose an advanced toggle on the Project Keys page, and extend internal config overrides to support a new `project` level; E2E/tests and schema fuzzing are expanded accordingly, and CI adds a forward-compat migration check job when back-compat fails. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 5d06c08613. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Project-level config to require publishable client keys; migration applied to existing projects. * **Improvements** * Auth flows now support optional publishable client keys with explicit validation and a sentinel for keyless OAuth. * Dashboard/UI and SDKs handle publishable keys as optional and conditionally show/generate them. * Admin/client APIs extended to manage project-level overrides. * **Bug Fixes** * Key validation behavior aligned with project config. * **Tests** * Expanded E2E and unit tests covering optional/required publishable-key scenarios. * **Documentation** * Spec and knowledge docs updated to describe the sentinel and config behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-02-19 10:23:16 -08:00
Konstantin Wohlwend	e5a354617c	Fix restricted user schema	2026-02-11 10:52:55 -08:00
Aman Ganapathy	c8694c7ff5	[Fix] [Feat] Update OAuth Sign-In and Get Token Functions to Work (#1130) ... ### Summary of Changes Previously, on the Swift SDK, the `signInWithOAuth` function wasn't working. In this PR, we fix it by having the `getOAuthUrl` function to actually redirect correctly. Note that to do so, we updated the `validRedirectUrl` check on the backend to accept app native redirects (from our new trusted url scheme). Another thing to note is that we added functionality to the `TokenStore` abstraction to conditionally refresh the access token that the user is trying to fetch if it is expired/close to expiring if possible. `getOAuthUrl` will attempt to get a valid access token, and thus will rely on our algorithm documented in `utilities.md`. The specs serve as the source of truth. We go further and implement Apple Native sign in. To do so, we have it hit a new route on the backend and verify the `jwtToken` retrieved by the sdk against an Apple-provided set of `jwks`. We use jose to do so, in line with the rest of the codebase. We take this opportunity to refactor the oauth provider route owing to the amount of duplicated logic. Additionally, to enable the apple sign in, users will have to update the Apple authentication method modal on the dashboard and add accepted bundle ids. These are identifiers for projects, and we will check the `JWT` on the backend to make sure the audience is set to an accepted bundleId. We also update the Apple modal to be more informative. ### Using the new Features To use the Apple native sign in, users will have to 1) sign up with an apple developer account, 2) set up their bundleids for their projects by connecting them to the apple developer account, 3) update the Stack-Auth Authentication Methods dashboard apple modal with the relevant fields. Then, trying to sign in with apple with our Swift SDK will use the apple native sign in. ### UI Changes Renamed the fields in the apple modal. Added a new field for bundle ids. See below. https://github.com/user-attachments/assets/0e760c0e-3198-4818-ac7f-4900d7a125bb Co-authored-by: Konstantin Wohlwend <n2d4xc@gmail.com>	2026-01-28 02:17:27 +00:00