replying to @dtinth
Today the app makes you paste <code>#<state>. Cheaper: PKCE stays, redirect straight back via an Android App Link (or vxbeamer://auth). One extra redirect URI in the provider, no pasting. Want the plan?
Commit
56e8cd1
- I like PKCE because it prevents the code from being used by others.
- Problem with redirection is that it assumes that I am signed in to OIDC provider on the same machine.
- Also right now web client has to implement 2 different flows.
- I am thinking of something like…
Agreed, redirect is out. Do device flow in our backend: app gets a code + QR; your signed-in web client approves it; app polls and gets tokens. Web keeps ONE OIDC flow, app has none. No provider change. Sketch it?
On my iPad, I use the PWA. The PWA app can’t really do the OIDC flow because when I get to Google Sign In, it shows me as logged out despite me signed in to Google in Safari.
Makes sense: an iOS PWA has its own cookie jar, so Safari login does not carry over. So the PWA is a pairing client too, not only the app. Then who approves? Safari (signed in) or an existing device?
I am thinking about… what if vxbeamer's backend has a bare-bones web interface for the web/android/3rd party client to pair
Good fit: backend serves /pair, one origin, one OIDC flow (Safari, where Google works). Client opens it with its code; you approve; it polls for tokens. All clients share it. Sketch endpoints?
Yeah, so previously the client does the OIDC dance, now it's the backend who does it and lets client pair. Am I understanding you correctly?
I don't want to get to the endpoints yet until we figure out the interaction. How would sign in work for these after we revamp the auth…
Yes, you got it. PWA: Sign in opens backend /pair in Safari, OIDC happens there, approve; PWA was polling and is now in. Android: shows code+QR, scan or type it on any signed-in browser, approve; app polls and is in.
Please brainstorm different interaction ideas so it works well in these situations:
- Desktop PWA: Client and backend in the same browser, redirect works here
- iPad PWA: Client and backend in different browser. Redirect doesn't work, but being on the same machine, copy and…
Brainstormed 6 ideas and ran a small tournament.
Ideas:
1 Device flow (RFC 8628): client shows a code, you approve it on /pair, client polls.
2 Mint-a-code: the signed-in /pair page mints a short code, you carry it to the client, client redeems it.
3 PKCE round trip: client…
I like no.2, but if code is short, potential attackers can brute force. Might be cool if the code also includes the backend URL so we can remove Backend URL from the settings page.
Both good.
Brute force: make the code 12 chars (60 bits) plus a per-IP rate limit and a 2 min TTL. Only a few codes are live at once, so a guess almost never hits.
Backend URL: make the pairing string a link, https://<backend>/pair#<code>. The client takes the origin as the…
All clients should be backend agnostic tho. We don't have a public backend here. I am fine with long code tho. If the desktop has a camera it can scan the phone's QR code.
Agreed, and that fits: the pairing link carries the backend, so a client never hardcodes one. Same client works with any self-hosted backend.
So the final shape:
- Backend /pair mints a code and shows it as a link + QR + Copy/Share.
- Any client takes that link (paste, scan, or…
Yeah and let's start building. For web client, I already built https://github.com/dtinth/qr with features like torch and camera switching. For Android, I don't know, you choose and tell me.
GitHubGitHub - dtinth/qr: A popup QR code scanner that can be easily integrated into a web app.A popup QR code scanner that can be easily integrated into a web app. - dtinth/qr
Correction to what I said earlier ("no provider change"): the backend has no login of its own today, the website does the OIDC dance. So /pair on the backend runs the code flow itself, and the provider must allow https://<backend>/pair as a redirect URI. One-time, per backend.…
The OIDC provider I am using is assuming consumer is a public client. Any downside of keeping that?
Backend pairing works end to end locally: /pair page, mint, redeem, single use, rate limited. 108 tests pass. Not committed yet, the pre-commit hook needs deps installed in the main checkout. Web and Android next.
Ok, continue. You can make a draft PR and push as you go.
Will do, draft PR + pushes. One blocker: the git hook needs deps installed in the main checkout and I may not write there. Please run: cd ~/ghq/github.com/dtinth/vxbeamer && vp install. Then I can commit. Writing the web part meanwhile.
commit 56e8cd1