Skip to content

feat: map Goodmeet native Google token requests (GOO-7772) - #22

Closed
gn-kim-k wants to merge 2 commits into
goodnotesfrom
feat/goodmeet-google-provider-compat
Closed

gn-kim-k wants to merge 2 commits into
goodnotesfrom
feat/goodmeet-google-provider-compat

Conversation

@gn-kim-k

@gn-kim-k gn-kim-k commented Oct 28, 2026 •

Copy link
Copy Markdown
Collaborator

Goodmeet's desktop and mobile Google clients obtain their own Google ID token, then POST method: OIDC, provider: google, id_token, id_token_nonce to Kratos. They do not use Kratos /callback/google. This change maps the legacy provider selection to google-goodsystems only 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 provider id: 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.ts selects engine.login for Google; desktop-google-connection.ts receives Google's callback on 127.0.0.1; the pinned account SDK POSTs its ID token to Kratos. Mobile performGoogleSignIn uses the Google SDK then createNativeKratosSession. 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:

go test -race -tags sqlite ./selfservice/strategy/oidc ./test/schema -run '^Test(IDTokenProviderAliases.*|Config|GenerateState.*|GoogleVerify|MicrosoftVerify|MicrosoftClaims|FormHydration|ClaimsValidate|ProcessIDTokenVerifyErrors|Schemas)$' -count=1

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/kratos provider 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 maintained goodnotes, not an upstream merge.

Checklist

  • Read contributing guidelines and security policy; fork target follows AGENTS.md (goodnotes).
  • Referenced GOO-7772 and documented the configuration contract.
  • Added behavioral regression/schema tests and formatted touched Go files.
  • This does not address a reported security vulnerability.
  • Updated configuration schema and companion deployment/migration docs. No upstream Ory docs change is included.

Further Comments

Publish the planned compatibility image v1.3.0-gn-v15 after merging this PR, before deploying the draft config. The maintained base includes v13 Microsoft raw-claims support and v14's explicit network.id startup 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.

@gn-kim-k gn-kim-k changed the title [GOO-7772] Preserve public Google ID for Goodmeet migration feat(oidc): preserve public Google ID (GOO-7772) Oct 28, 2026
@gn-kim-k gn-kim-k changed the title feat(oidc): preserve public Google ID (GOO-7772) feat: preserve public Google ID (GOO-7772) Oct 28, 2026
@gn-kim-k
gn-kim-k marked this pull request as draft October 28, 2026 10:17
@gn-kim-k gn-kim-k changed the title feat: preserve public Google ID (GOO-7772) feat: map Goodmeet native Google token requests (GOO-7772) Oct 28, 2026
@gn-kim-k gn-kim-k closed this Oct 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant