Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Evert Pot <[e-mail]>]

On 2021-02-25 3:22 a.m., Seán Kelleher wrote:

> Just to clarify, I assume in this discourse that the "server" in this 
> client and server relationship refers to an AS/RS pair in OAuth 
> terminology? Based on this, one big sticking point for me on the 
> applicability of NxM, or even 1xM, is that all of the "M" RSs need to 
> publish the same interface for any meaningful implementation in the 
> first place.
>
> It probably makes more sense with email clients, since as Bron said, 
> there is the common standard of POP. If we assume that all the email 
> services that we want to connect to publish the same POP interface, 
> and would accept tokens in the same way, then the way the authZ is 
> handled is indeed the point of divergence that needs to be resolved.

The usefulness of this goes beyond standardized protocols / multiple 
implementors of an API. Some examples of what's possible with Basic 
auth, and not with OAuth2:

 1. I can point my browser to a Basic Auth-protected endpoint. I get a
    pop-up and it will let me log in.
 2. Basic auth is supported in tools like Curl.
 3. It makes generic clients more viable for things like APIs. SDKs for
    specific APIs can be helpful, but HTTP is the universal interface. I
    should be able to use a generic HTTP client and point it to a
    generic HTTP destination and for this to work.
 4. Similarly for the cases where there is a common standard
    server-side, implementors should not have to decide on an
    authentication system. If Auth is baked into the HTTP layer and
    widely supported, POP can be agnostic about how Auth is performed.
    This allows independent upgrading/decoupling of 'POP' and 'Auth'.
    Imagine if we had to update *every client* if a new TLS version is
    released? That's what OAuth2 is like now.

Evert