OAuth: link a social account from Android via Custom Tabs #39

Activity

1. Adron

   added

   parityClosing a gap against interlinedlist.comClosing a gap against interlinedlist.com

   blockedBlocked on something outside this repoBlocked on something outside this repo

   P1Big hole in a shipped featureBig hole in a shipped feature

   area:integrationsOAuth, cross-posting, GitHubOAuth, cross-posting, GitHub

   on Sep 15, 2026
2. Adron

   added a parent issue on Sep 15, 2026

   • Social account linking (OAuth) and full cross-post destination support #38
3. Adron commented on Sep 16, 2026

   

   Adron

   on Sep 16, 2026

   MemberAuthor

   More actions

   Blocked — cannot implement yet. Here is exactly what is needed to unblock.

   Picked this up in the parity sweep and stopped at the redirect contract. Everything else in the flow (Custom Tabs launch, intent filter, status confirmation, cancelled-flow cleanup) is ready to build the moment these are answered.

   1. Redirect URI scheme — which one is registered server-side?

   The server's /api/auth/{provider}/callback currently redirects to a web page. For Android we need one of:

   Option	Redirect target	Notes
   A. App Link (preferred)	https://interlinedlist.com/auth/android/callback	Needs /.well-known/assetlinks.json hosted on interlinedlist.com containing the app's package name + SHA-256 signing cert fingerprints (debug and release). Most secure — no other app can claim it.
   B. Custom scheme	interlinedlist://oauth/callback	No server hosting required, but any app can register the scheme. Acceptable with PKCE.

   Which do you want? If A, we also need the release keystore SHA-256 to publish in assetlinks.json.

   2. Per-provider registration

   Each provider's developer console needs the Android redirect URI added to its allow-list. For each of Mastodon, Bluesky, LinkedIn, X/Twitter, GitHub, please confirm:

   • Is the Android redirect URI registered?
   • Does the existing web OAuth client get reused, or is there a separate Android client id?
   • Does /api/auth/{provider}/authorize accept a redirect_uri (or return_to/state) query parameter so the app can ask to be returned to, or is the redirect fixed server-side?

   3. Token hand-off back to the app

   After /callback completes on the server, how does the app learn the result?

   • Does the callback redirect carry anything in the URL (e.g. ?status=ok&provider=bluesky), or is the app expected to just poll GET /api/auth/{provider}/status afterwards?
   • Is the linking performed against the bearer token the app already holds, or does it require the web cookie session? (Several /api/auth/* endpoints were previously observed to be cookie-gated — POST /api/auth/{provider}/link needs confirming for bearer auth.)

   4. Mastodon specifics

   Mastodon is per-instance. Does /api/auth/mastodon/authorize take an instance host parameter, and is app registration done server-side per instance, or does the client need to supply one?

   What I can do without this

   Issues #40, #41, #42 and #43 in this epic do not depend on the OAuth round-trip and are being worked separately.

   Leaving this open and unimplemented until the above is settled.