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

[Warren Parad <[e-mail]>]

I don't think flooding this thread with random libraries is going to
benefit anyone, so let's not do that.

Back to the question, and it is an interesting one. It makes sense to
dissect it a bit first. Who is struggling with "OAuth libraries" and what
is even the responsibility of one of them.

*I'll start with my recommendation:*

   - 0) We shouldn't build anything, and we shouldn't curate lists of
   libraries and packages.
   - 1) We should make this information about libraries discoverable and
   trackable. For instance with AS discovery docs we can enable adding
   properties that link to SDKs in languages that the AS decides to support.
   - 2) We can document a "discovery doc" for libraries to self publish
   detailing their features (in case they aren't associated with an AS). Then
   anyone who wants to build lists of libraries with supporting features, can
   easily compile these documents. All we have to do is define "OAuth SDK
   features", and this will enable everyone else to create SDK
   listings/feature comparisons. It can even be automated.

*My concerns:*
I think we have to break it down first into some key areas:

   - There are OAuth user-agent clients
      - Mobile app clients for each of the app os, and further for each of
      the app development frameworks
      - Web apps
      - Desktop apps
   - There are OAuth machine clients
   - BFF oauth code exchange clients
      - client credentials clients
      - third party machine clients
      - leaf clients that need to validate authorization tokens
      - [One caveat to this is that these can and will be written in every
      possible language available]
   - There are OAuth Authorization servers
   - Open source ones
      - SaaS models
      - AS in a container
      - embedded cloud native solutions
      - potentially user controlled

Obviously this isn't a full list, but looking at each of these,
specialization in the world of software libraries tells us that likely
every one of these could and will be its own library. Just looking at this
shortlist, and the story of "which library" should you use becomes
incredibly complicated. If we have libraries that purport to solve all
these problems, then it becomes a gratuitous burden on developers to pick
the right library, which isn't interchangeable with others. They aren't
pluggable.

Additionally, for the purposes of branding and documentation, most of these
will be wrapped by brand specific implementations so that careful
validation and control over key features can be communicated. Further,
since the landscape moves quickly providers want to stay up to date,
putting links all over your documentation pages saying "this library does
not yet support said feature" is terrible. This is still frequently the
case, and so providers are encouraged to lie, "We support this*" - but you
have to do these hacks after you download the library to support it.

Further, there are sane defaults that make sense for a wrapper for a
dedicated and opinionated solution that don't make sense in a generic one.
The whole class of AS libraries are hidden from external developers, so
there is very little value in a "whole solution" and more value in
delivering what these AS need. Since they have their own motivations, they
are already either open sourcing their solutions or keeping it closed and
won't contribute. This is arguably the set where libraries offer the most
value, but because of these reasons it is a lost cause.

The second set is machine clients. Most of this is very similar to the last
section of AS, but very little of it is OAuth specific. Most of it is "Add
an authorization header" or "call this specific endpoint one time". A
couple of lines in the documentation is sufficient for handling this. Which
leaves "How to verify an OAuth token". Having built a library for tons of
languages to handle not just OAuth but other things, the challenge here
isn't the OAuth part. Sure there is some knowledge around how to convert
the *issuer* to the JWK using the discovery document, but a library only
marginally improves the state. And the amount of work for branded libraries
to add this in is still trivial. The real problem with these is that the
crypto communities in different languages don't make it easy to do this. If
you think explaining OAuth is challenging, try to explain libsodium
requirements, they don't care, and we can't fix that with a library. We can
fix that by contributing to the available crypto tools so OAuth
verification can be easier. Thankfully we don't have to, because the
branded products will release their open source version implementing or
fixing these because they are motivated to do so.

Now I get to the OAuth user-agent/facing clients. Web apps complexity here
is usually the framework, and dance around, what do I do with the state,
and the redirect so the user ends up in the right place. A library isn't
going to fix that, and even if it did, it isn't OAuth that is the issue
here, it is a lack of good browser apis to support easy navigation.

Which leaves us with, are we talking about mobile apps or desktop clients?
Because we are talking about one of these other categories, there isn't
enough value in there to list them any more than there is value in listing
OIDC providers that support OAuth. Being met with a list of hundreds of
libraries and packages doesn't make for a good experience, and do those
same developers know if they need PKCE, EdDSA signatures, a library that
supports mTLS, probably not.

- Warren

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Mar 2, 2022 at 4:33 PM Sascha Preibisch <[e-mail]>
wrote:

> Hello Daniel!
>
> Some time ago I started an open source project: Loginbuddy.
> Loginbuddy is a tool that mainly supports OpenID Connect based logins.
>
> It can be deployed as a standalone service or be used as a side-car next
> to other docker containers in the same network.
>
> Although it is not necessarily a library, it may be worth looking into it.
> I could imagine that Loginbuddy would also be a good starting point for
> extensions that serve more flows and more general features of OAuth/ OpenID
> Connect. With more contributors I see a chance for Loginbuddy to be more
> widely used and help address your concerns.
>
> Please have a look here:
> https://loginbuddy.net
>
> I just updated the web site. Or visit the GitHub project:
> https://github.com/SaschaZeGerman/loginbuddy
>
> In any case, that is my current contribution to the developer community.
>
> Thanks,
> Sascha
>
> On Tue, Mar 1, 2022 at 9:18 AM Daniel Fett <[e-mail]> 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 <http://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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>