> On Mar 1, 2022, at 10:18 AM, Daniel Fett <f...@danielfett.de> wrote:
>
> * The core of OAuth is easy to implement. The need to create or use a
> library might not be obvious to developers. Of course, if you want a proper
> implementation with correct error handling, observing all the security
> recommendations, etc., the effort is huge. But just getting OAuth to work for
> one specific use case is relatively easy.
I’d argue this point - it is not easy to implement. It is far easier to
describe.
The separation between codes, refresh and access tokens means that you have
logic from a library being integrated at multiple levels, from API access to
persistence to user presentation. There are also complexities that arise - any
API call could require changes to persistence or new user interaction.
Because of the variability in the kinds of applications which could be
supported, many libraries wind up looking like simple message object builders,
with complex state and processing mechanisms underneath that do not necessarily
map at all into the application architecture. On top of this you have to extend
your own app with the communication and asynchronicity required.
> * OAuth is traditionally hard to configure: authorization and token
> endpoint URLs, client id and secret, supported scopes (and claims for OIDC),
> supported response types and modes, and required security features are just
> some of the things a developer has to figure out - often from the API's
> documentation
I find the OAuth Server Metadata response to be a good format for the server
configuration (even if not hosted via well-known, or if it is client-specific),
and the client metadata from RFC 7591 to be a good start.
<snip>
> What can we do about this?
<snip>
> * The OpenID Foundation has a great set of conformance tests for OIDC, FAPI
> and other stuff. Creating conformance tests for OAuth would be harder, given
> that the framework leaves many options for implementers to choose from. I’m
> not sure if running a conformance programme would be in the scope of IETF,
> but it can be worthwhile to think about if we could support such an endeavor.
I would suspect it would be adding more constraints to profile behavior (beyond
what we have done already in say the Security BCP) and then having tooling and
conformity assessments based on that profile. My scope suspicion is that
tooling and testing would be external.
<snip>
> * The single most important thing to do would, in my opinion, be to set a
> goal: Tell library developers and language maintainers what can be expected
> from a good, modern, and universal OAuth library. Such a recommendation would
> shine a light on the most important extensions for OAuth like PKCE and might
> even be a prerequisite for conformance tests. It may turn out to be OAuth 2.1
> or something else. For me, this would in any case include AS Metadata, as
> that is the single most valuable building block we have to address
> configuration complexity.
The only wrinkle I would add is that pre-established clients may have per
client AS metadata, but the AS metadata format itself (e.g. JSON with specific
keys) is still useful for representing that in a consistent manner as a format
(rather than an endpoint). I have seen some slight extensions there, such as a
parameter to provide JWK information inline.
Client metadata is harder, as there may be information in both the request and
response that needs to be understood, as well as local configuration and
secrets (such as private keys). There is also a chance for reproduction as well
as uncaught differences when supporting multiple distinct AS as a client.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
