I think it's more like the "service_documentation" URL in AS metadata where
it provides a page the user can visit in a browser:
https://datatracker.ietf.org/doc/html/rfc8414#section-2

It's not an API endpoint like the FAPI Grant Management API.

The app would just provide a link to it and open the browser to that URL so
the user can log in and manage their authorizations there.


On Mon, Nov 17, 2025 at 12:39 PM Warren Parad <wparad=
[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. <emelia=
> [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 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]
>> To unsubscribe send an email to [email protected]
>>
> _______________________________________________
> OAuth mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to