Repository navigation
Conversation
gn-kim-k
marked this pull request as draft
October 28, 2026 10:17
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Goodmeet's desktop and mobile Google clients obtain their own Google ID token, then POST
method: OIDC, provider: google, id_token, id_token_nonceto Kratos. They do not use Kratos/callback/google. This change maps the legacy provider selection togoogle-goodsystemsonly for ID-token login/registration requests.Related issue(s)
GOO-7772. Accounts pointer writer: merged GoodNotes-5#66758. Goodmeet deployment config: draft GoodNotes-5#66808.
Implementation
Add optional
selfservice.methods.oidc.config.id_token_provider_aliases. Goodmeet alone sets{google: google-goodsystems}and configures the canonical providerid: google-goodsystems.Login and registration consult the mapping only when the submitted ID token is nonempty, before the normal provider verifier and credential lookup. Stored credentials, hook provider IDs and completed sessions use the canonical provider. Subject, signature, audience and nonce handling remain unchanged. Direct canonical input remains accepted.
Generic provider lookup, browser forms, identifier-first choices, OAuth state, callback URLs and settings retain their exact-ID behavior. There is no HTTP redirect, body replay, callback alias, second Google provider, dual-write window or client change. Classic and other product deployments omit the mapping and retain their current settings/images.
Client trace: desktop
main.tsselectsengine.loginfor Google;desktop-google-connection.tsreceives Google's callback on127.0.0.1; the pinned account SDK POSTs its ID token to Kratos. MobileperformGoogleSignInuses the Google SDK thencreateNativeKratosSession. Both exchange only the resulting Kratos session token with PAD through the existing path.Tests and proof
Observed failing-then-passing real HTTP regression: the initial flow rejected the unsupported alias configuration; native login/registration now return canonical product sessions and reuse one product identity while preserving the separate Classic binding.
Boundary tests verify missing-token submissions use exact lookup, invalid tokens are still rejected, an unconfigured product deployment rejects legacy Google, direct canonical requests still work, and Classic resolves its original identity. They use signed synthetic Google tokens, local JWKS, the real Google verifier and SQLite. Schema fixtures cover valid mapping and invalid target types/empty targets.
All 119 test/subtest outcomes pass, with zero failures/skips, under Go 1.26.1 and the race detector:
No live Google/Goodmeet/PAD sign-in, image publication, deployment or database backfill was performed. External review of this narrowed version is pending export approval; earlier review results apply to the earlier diff.
Upstream investigation
Checked
ory/kratosprovider configuration and path commit98aaf210, plus provider alias/rename and native-token issue/PR searches. No applicable provider-ID remapping option or patch was found in that scope. This is a local change against maintainedgoodnotes, not an upstream merge.Checklist
goodnotes).Further Comments
Publish the planned compatibility image
v1.3.0-gn-v15after merging this PR, before deploying the draft config. The maintained base includes v13 Microsoft raw-claims support and v14's explicitnetwork.idstartup requirement. Startup configuration and migration-writer access to both product and Classic identities must be ready alongside the separate product-pool work (#66788/#66789/#66804 in GoodNotes-5). No network selection/move or cross-network lookup implementation is included here.Previous-head CI had dependency-scanner findings and a Playwright browser-dependency installation failure on Ubuntu noble; this PR changes no dependencies or workflows. See scanner and Playwright SQLite job. New-head checks are tracked separately.
PRD opt-out: backend provider compatibility preserves existing client sign-in entry points; no desktop UI change. Skipped grill: scope explicitly requested by the product owner after tracing the current client path.