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

Hi Daniel

I do think it’s a problem that’s worth addressing somehow.

I think there’s another factor, which is that the providers of OAuth2 Authorization Servers (where they don’t have their own SDKs specific to their server) tend to lead the developer through how to do a “from scratch” implementation of OAuth2 and rarely if ever mention any libraries. (So a chicken and egg problem, because as you note there are languages without obvious good libraries to point people at.)

There’s even a set of documentation I’ve seen that links to an online PKCE generator and appears to imply that the developer should just generate the values once and hardcode them into every request…

I agree that pushing AS metadata will help matters. One of the downsides of maintaining OAuth2 libraries is dealing with constant “bug” reports when the library appears to a naive developer not to work correctly with a particular provider.

I’ve found https://jwt.io/libraries <https://jwt.io/libraries> a very useful reference for JWT libraries; anything of a similar nature for OAuth libraries sounds good to me.

Joseph

> On 1 Mar 2022, at 17:18, Daniel Fett <fett@danielfett.de> wrote:
> 
>  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 <https://danielfett.de/>_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth