> One question I have here is, how do you envision connecting from the > publishing of the authorization_management_uri, > to it actually being used practically?
I'm going to submit a pull request to Bluesky's open-source Authorization Server implementation (it's in their PDS), following discussion with their team. (I already contribute to that code). As to whether this makes sense for more traditional OAuth setups where you have a "primary" application with a web UI on the same hostname as the authorization server, where there isn't really this sort of discovery problem, I'm not sure this would apply. In AT Protocol, effectively all client applications are third-party applications to the PDS, which is the authorization server for self-hosted (or the "entryway" is, in a setup like Bluesky's hosted PDSes). The client applications are separate from the authorization-server and there is no primary application. I should also note that I'm not 100% sold on the name authorization_management_uri, and would be open to changing it, but it was the first thing that came to mind for what I'm trying to describe. — Emelia > On 17 Nov 2025, at 21:38, Warren Parad <[email protected]> > wrote: > > Can I just say, I really hate this is a problem, and I love the idea of > trying to standardize something here. Because, as a user of many different > services, where I have in the past given out access to, it's near impossible > to know where and how to revoke access to some of those things. > > One question I have here is, how do you envision connecting from the > publishing of the authorization_management_uri, to it actually being used > practically? > > On Mon, Nov 17, 2025 at 9:11 PM Emelia S. > <[email protected] > <mailto:[email protected]>> wrote: >> Hi all, >> >> I've recently encountered an issue with OAuth for decentralized social web >> applications (e.g., those built on AT Protocol), >> where the user may not be directly familiar with their Authorization >> Servers' UI because they normally use apps to access >> their accounts. >> >> For instance, many Bluesky users don't know how to access their >> Authorization Server's management UI for managing >> which clients have access to their account, as documented in >> https://github.com/bluesky-social/social-app/issues/9403 >> >> This has lead many users on Bluesky to think that App Passwords (effectively >> additional passwords for their account) >> are more secure than OAuth, because the Bluesky client application cannot >> provide a management UI for OAuth clients, >> since it is not the authorization server. The authorization server is >> instead bsky.social <http://bsky.social/> when people use bsky.app >> <http://bsky.app/> as the client. >> >> I noticed that in the Authorization Server Metadata (RFC8414) there wasn't >> particularly a relevant property besides maybe >> homepage_uri (from OpenID Federation) through which to expose the management >> UI. >> >> So I'd like to propose a `authorization_management_uri` property, and have >> submitted an internet draft to enable discovery >> of the management UI: >> https://www.ietf.org/archive/id/draft-emelia-oauth-authorization-management-uri-00.html >> >> n.b., I know there's a typo in the security considerations section, I caught >> it after publishing -00 and didn't want to publish a >> new version just for changing one word. >> >> Yours, >> Emelia Smith >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
