Repository navigation
Device keys, proofs and the browser sign-in - #20
Merged
Merged
Conversation
Refresh tokens are bound to a key the device makes at sign-in, and refreshing needs a proof signed by it. Sign-in, account creation and account management move to the cloud's web pages; the launcher starts the browser flow through the net service (browser_sign_in, cancel_sign_in, account_page). New crate anyplay-proof: device keys, proofs, PKCE and the loopback redirect check. API: Device.key, device_key at refresh, browser/token, browser/link, Info.web. Specification, glossary and ADR 0016.
Member
Author
|
The cloud half is anyplaynet/cloud#25. It builds against this PR, so it stays red until this one is merged. |
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.
Accounts are managed on the web, and refresh tokens are bound to a key on the device, so a copied token is useless elsewhere. The cloud half is anyplay-gg/cloud (see the link in the comments); that PR builds against this one, so merge this first.
What changes
browser_sign_in,account_page); e-mail, passkeys, recovery and later Apple, Google and Discord sign-in live on the cloud's web pages. It also holds the design of the token format, the device key, proofs, reuse detection, "sign out everywhere" and passkeys.crates/proof(new):DeviceKey(Ed25519), proofs (AnyPlay-Proofheader, 60 seconds, once), PKCE S256 and the RFC 8252 loopback check. Test vectors, one cross-checked with Node's crypto.crates/api:Device.key,RefreshRequest.device_key,BrowserTokenRequest,AccountLink,Info.web, pathsauth/browser/tokenandauth/browser/link.crates/net: makes a device key at each sign-in and keeps it in the same entry as the refresh token; every refresh carries a proof; a saved sign-in from before keys makes a key and binds on its first refresh. The browser flow: loopback listener (random port,Hostcheck,statecheck), PKCE, token exchange.account_pageasks for a one-time link with a proof.crates/control:browser_sign_in {create},cancel_sign_in,account_page,Pending::Browser.email,codeandsign_upstay and are marked deprecated.cloud-api.md(tokens v2 with test vectors, proofs, devices without a key, browser sign-in),control-protocol.md,CONTEXT.md.Tokens
Access and relay tokens are
v2:kid,audandiatin the payload, signature over a domain separator.v1tokens are still read. This is in the cloud PR (crates/ticket); the spec here has the vectors.Migration for existing devices
A device signed in before keys has 30 days to refresh as before. The net service of this version binds it on its first refresh; after the 30 days it must sign in again (spec: "Devices without a key").
Checked
cargo fmt --all -- --check,cargo clippy --workspace --all-targets -- -D warnings,cargo test --workspace,cargo deny check,rules.mjs. The cloud PR runs the whole chain (net service, browser, cloud, token exchange, refresh with a proof) incrates/e2e/tests/browser_sign_in.rs.Not done here
The launcher buttons (someone else). A real browser and a real authenticator were not used; the cloud tests use a cookie-jar client and webauthn-authenticator-rs's software passkey.