feat(supabase_flutter): Android Restore Credentials on top of passkeys - #1824
Open
spydon wants to merge 2 commits into
Open
feat(supabase_flutter): Android Restore Credentials on top of passkeys#1824spydon wants to merge 2 commits into
spydon wants to merge 2 commits into
Conversation
Adds RestoreCredentialInterface and the createRestoreKey and signInWithRestoreKey helpers so an app can meet Google Play's Restore Credentials requirement with a Supabase passkey as the restore key. Closes #1791
Contributor
|
Warning Review limit reachedNext included review available in 38 seconds. View limit detailsLimit details: You’ve used all 4 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Tr00d
approved these changes
Sep 10, 2026
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.
What kind of change does this PR introduce?
Feature. Closes #1791.
What is the current behavior?
Google Play requires apps with sign-in to restore the signed in state on a new Android device through Credential Manager's Restore Credentials API from April 2027. The issue asks for a server-issued single-use restore token because storing the rotating refresh token is unsafe: a stale copy replayed from a backup trips refresh token reuse detection and revokes the whole session family.
The requested token already exists in a different shape. A restore key is a WebAuthn credential; Android documents that the server side is identical to passkeys. Supabase Auth ships passkey endpoints (
/passkeys/registration/*,/passkeys/authentication/*) withuserVerification: preferred, so a silently created and silently asserted restore key is accepted, and signing in with it opens a fresh session that is independent of the old device's refresh token chain.supabase_authalready exposes those endpoints throughauth.passkey, but nothing connects them to Android'sCreateRestoreCredentialRequest/GetRestoreCredentialOptioncontract, and the README says nothing about the requirement.What is the new behavior?
supabase_fluttergains a thin layer next to the existing passkey helpers:RestoreCredentialInterfacewithcreateRestoreCredential(requestJson)andgetRestoreCredential(requestJson), mirroring the twoandroidx.credentialscalls. Both sides speak WebAuthn JSON strings, which is what Credential Manager accepts and produces, so wiring a Credential Manager plugin or a platform channel to it is two one-line forwards. Like the passkey helpers,supabase_fluttertakes no dependency on a specific plugin.AuthClient.createRestoreKey(restoreCredential, {friendlyName})runs the registration ceremony for the signed in user and then names the passkey (Android restore keyby default) so restore keys can be told apart from user-created passkeys and hidden from a management screen, which Android's guidance asks for.AuthClient.signInWithRestoreKey(restoreCredential, {captchaToken})runs the authentication ceremony on the new device, persists the session and firessignedIn.sdk-compliance.yamlunder the existingauth.passkey.register_passkeyandauth.passkey.sign_in_with_passkeycapabilities. No new canonical IDs.Both helpers are
@experimentalbecause they build on the BETA passkey feature.Additional context
Server-side limitations that a GoTrue change would remove, none of them blocking:
listfilter them out.max_passkeys_per_user(default 10). There is no TTL.Not included: a native Android plugin inside
supabase_flutter, for the same reason the passkey helpers do not bundle one. Thepasskeysexample stays web-only, so it does not exercise the new helpers.Testing: unit tests drive both helpers against a fake platform implementation and a mocked passkey server, checking the request sequence, the JSON handed to the platform, the credential posted back, the rename, error propagation and the session/event on sign in. The ceremony against a real device was not run.