**
*Hi all,*
*
While helping clients to onboard into the yes ecosystem, in my
consulting work, and in discussions with developers implementing OAuth
2.0, one topic comes up increasingly often: The (somewhat frustrating)
lack of good, modern, and universal OAuth libraries.
Many of the libraries out there have one or more of the following drawbacks:
* They are not maintained any longer
* They are not well documented (e.g., it is often unclear which
specifications are supported)
* They support only a subset of the OAuth 2.0 specification
* They work only with selected providers (e.g., Google, Facebook, etc.)
* It is unclear whether they follow recent security recommendations
* They do not support modern features, such as PKCE, AS Metadata,
MTLS, etc.
Exceptions exist, of course, like Filip's Node.js implementation and the
nimbus library for Java. But apart from those rare cases, when a
developer asks me what library to use, my answer is often: "I don't
think there's a good one in your language". It is a telltale sign that
many providers of OAuth protected APIs also provide a custom OAuth
implementation in their SDKs, which they then often have to maintain for
a number of languages. This creates unnecessary costs and friction,
e.g., when introducing new security features.
At the same time, practically every language/framework comes with a TLS
stack and making HTTPS requests is often just a few lines of code. Why
aren't we there yet with OAuth? I'm well aware that OAuth 2.0 is a
framework, not a single protocol like TLS, but the mentioned libraries
show that this does not preclude a comprehensive library support.
If I had to speculate about the reasons for this mess, I'd say that
there are three:
* 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.
* 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 - to get everything up and running.
Even though configuration is not the same as implementation, I imagine
that this complexity can lead to the perception that there are barely
any commonalities between different OAuth flows. There might be no
value, after all, in an OAuth library, if I have to provide so many
details myself.
* With many extensions and specifications to choose from, it can be
hard to select a reasonable subset to support.
What can we do about this?
I'm not sure, but I have a few ideas.
* Of course, one step would be to increase visibility and
documentation for existing implementations: Beyond listing libraries
(like the list on oauth.net), it would be great to have a place to go to
to find libraries based on their feature support. I'm sure there are
more good libraries out there.
* 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.
* 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.
I would be interested to hear what others think about this. Is this a
problem worth addressing? Are there other solutions? Is this out of
scope of our work here?
-Daniel
*
--
https://danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
