FASP should rely on OAuth 2.0 discovery mechanisms, instead of hard-coded endpoints

[ThisIsMissEm]

The OAuth 2.0 endpoint to request an access token MUST reside at the path /oauth/token that is relative to the base URL as described above. Existing fediverse software that already uses OAuth 2.0 and wants to add FASP support cannot re-use existing routes. This simplifies FASP implementation and enables fediverse software implementers to separate their existing OAuth 2.0 implementation for regular API clients from the FASP API if so desired.

I'd recommend not using a hard-coded endpoint, instead relying on OAuth 2 discovery via authorization server metadata: https://datatracker.ietf.org/doc/html/rfc8414

Additionally, I'd not recommend having two OAuth endpoints, however, you could have a requirement that prevents a client from requesting both existing scopes (e.g., profile or read:followers) and FASP scopes. i.e., "If a client requests a scope that is within the FASP prefix, then it must not request unprefixed scopes".

Whilst having two OAuth endpoints may seem like it simplifies implementation, it increases security attack surfaces.

[oneiros]

Thank you for opening this. I had almost done the same, because this is really the point where I had most doubts.

I think we need to separate the two directions here: When a fediverse server calls APIs from the fasp I think it is really simple. No fasp implementations currently exist (besides a little prototype I cobbled together). So we have a blank slate and can just define the token endpoint. This makes it easy to implement without obvious downsides.

The other direction is really tricky, because many fediverse servers will already implement oauth, so the question becomes: What is easier to implement, while still staying secure?

For Mastodon the answer is pretty clear: We already implement the discovery and while doorkeeper lets you define routes twice, you do not get any real separation between different parts of the code anyway. So your assessment is spot-on.

But I have no idea how this looks for other implementations. Discovery might mean one more step in implementing this for fediverse server software if they do not already support it and it is definitely an additional step in implementing fasps.

And while I agree that more OAuth endpoints mean more attack surface in principle, I can also imagine people making a case for a strict separation. If the fasps' and regular API endpoint's OAuth implementations are strictly seperated, then there is zero risk of a fasp ever getting regular user's permissions.

But this rests on the assumption that there are oauth server libraries that make this possible in a reasonably easy way (again, doorkeeper does not) and that implementers actually want this.

Personally I have very little confidence in my assessment of the situation. Since you are the only person that has commented on this so far I tend to lean in your direction.

But really, I would love to get more feedback, escpecially from implementers.

If I do not get any, I will probably take a closer look at popular fediverse software and try to figure out how their OAuth implementations work to get a better picture.

[oneiros]

No longer relevant due to #27