[OAUTH-WG] OAuth: The frustrating lack of good libraries

[Daniel Fett <[e-mail]>]

**

*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