The logic for serving and storing associations between users and apps
Integrating loggedin.fyi — Documentation
Add your Atmosphere app to loggedin.fyi: publish client metadata, embed the interface, and start a normal OAuth login from a hinted DID.
Cross-App Authentication on AT Protocol
We recently built cross-app authentication between Roomy and OpenMeet using AT Protocol service auth JWTs. The idea came from @erlend.sh (his writeup), @zicklag.dev introduced me to PDS service auth, and @meri.garden contributed reviews. I made the implementation in both apps: A user logs into Roomy, navigates to an OpenMeet event, and is silently authenticated and able to use their account on OpenMeet without a second login. Full technical writeup: Cross-App Authentication on AT Protocol I’m ...
Atmospheric Login Page
The UX decisions behind my Atmosphere apps login pages — saved handles, handle autocomplete, and a 'create account' guardrail that slows people down on purpose.
PDS: review existing oauth scopes via connected apps list · Issue #4838 · bluesky-social/atproto
Scenario I want to stay on top of which apps are messing with what in my PDS. To do so, it's not enough to just make a granular Goldilocks decision once per app. (The more apps I use, the fewer...
The Case For Universal Login and "Off-Protocol" Services
Open Social Web ID - Erlend’s notes
Approaching a shared method of single sign-on for the entire open social web.
Follow a random chunk of users from someone else's list
Link to source code. I'm not logging anything on this server, at least not on purpose, but you should still probably use an App Password then delete it when you're done.
note again this doesn't correspond to user traffic. e.g. some app might use typeahead.waow.tech 's endpoints for actor search in other places than login, and another app might have a bad oauth impl that forces users to login more still fun to look at tho!
standard-reader.app vs pckt · typeahead traffic
typeahead.waow.techWe all like to talk about the login page a lot on here so I wrote a blog post about the pattern I've iterated on through @kich.io, @atstore.fyi, @cocore.dev, and @standard-reader.app Spoiler: we're making it too complicated for ourselves
Atmospheric Login Page
hipstersmoothie.comStandard Reader now publishes permission scopes! In human: When you log in we better explain what we're requesting and why The first one grants access to write data for our app, the second lets up create @standard.site subscriptions and likes for you
Claude is inheriting a centralized app-centric bias here (which existing OAuth profiles may share) To wind up in a decentralized world where all "my data" lives on "my PDS" -- regardless of how many atproto apps I authorize to store stuff there for me (see 🧵) -- we should invert that paradigm
Paul Rohr
TL/DR = yes, it's a subtle conceptual shift: - from app-centric (apps control identity/data, delegating access to you at signin) - to identity-centric (you control identity/data, delegating access to apps at signin) Really looking forward to how the team evolves the OAuth UX to address this! /END
Implementing dynamic OAuth scoping so that people who don't want to give any Bluesky permissions can still log in to Streamplace. Do I gotta implement a totally separate metadata document? Currently we're at stream.place/oauth/upstream/client-metadat… but that has the scope inline... cc @thisismissem.social
