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

Warren Parad <wparad@rhosys.ch> Wed, 02 March 2022 17:29 UTC

Return-Path: <wparad@rhosys.ch>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D2D3A0926 for <oauth@ietfa.amsl.com>; Wed, 2 Mar 2022 09:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzLQLDfqnSkD for <oauth@ietfa.amsl.com>; Wed, 2 Mar 2022 09:29:40 -0800 (PST)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AD03A0920 for <oauth@ietf.org>; Wed, 2 Mar 2022 09:29:40 -0800 (PST)
Received: by mail-yb1-xb33.google.com with SMTP id h126so4872672ybc.1 for <oauth@ietf.org>; Wed, 02 Mar 2022 09:29:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CwjwoT7X9yD1zXTUU/QuVAWaRLQ86LRe1+EBVf0QfmY=; b=bWY3XG1NesnrV5yc29kklaKbbd0fpepuckMiqfCKnRAs8HYO40EbNWbTb2BEtRsZwV uKEtCFTPH+Yy16UQPUYFKKK1OknLqU7G1DO+qI+OV0YslXuWjw2kS5UPRavlNzeqKqXM gZNsZcxDenKwtCQYUbsMo8RT17SBndnr9/xJKGS+4uhmwT94+u9peEKwx4jL9yxFJ/zs W+xvYvtYkTNMALf4xY6vttYJ3P5pmUEcWJJMg5QHWJSCvfrKbF9at9TbR5b57pz6Z1zP KGYyaU0bqsb55Wig47BIt0qp3AvmeOLfDs2R0g57LIzlEy6WdFJ/qDvwcRGIBFEQ6+9p gGiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CwjwoT7X9yD1zXTUU/QuVAWaRLQ86LRe1+EBVf0QfmY=; b=oFlBvsd7fU/W8GPxuOT3rd5vMqeHtwvZpHkTv8RZ7McondCMKa0QJtM3+BW8Y9zSYE 1ys7DEKzscYc+P+B/FzOCkNqZmqLgUG1sNRZd6eqY5zENVD3P1w2bQG81jItb7veylRU 8exWgOAPVYAZviBE92QOgZnHNZro2Y3CHSl7FFO0KHPobhQr46mn3tUEs/OeRZ8U5N+1 TIIV6g/YQnlSQEyhtF+m0OW4mN5pgnnSq0TBs8TUnD+p2Q/dBRdiOPY2ZVn3n7OpmlCm 17vsGBYctd5a3QFjXPmcGqRbBpzciUO1noHiK12879JJaaR73Q9VyaT9zj2VsEegHLS5 z8XA==
X-Gm-Message-State: AOAM533r6woipEJYv8EA45CkD7WQAOIGkT9+k7zT+eg58XplsWld5PUK nremNoaV0gIrAA+yOJ+piAxRKtaBDxcNzsPAUCi9
X-Google-Smtp-Source: ABdhPJyvuxC9ChVC6Yyg+5FqMC0AiGxNj3nuY7uIeLdIRAW/cqgI4WDOKvdQOn9ql+Va/b7reccLx64+DtttOy6sBUg=
X-Received: by 2002:a25:ef08:0:b0:628:8d01:870 with SMTP id g8-20020a25ef08000000b006288d010870mr6819613ybd.610.1646242179205; Wed, 02 Mar 2022 09:29:39 -0800 (PST)
MIME-Version: 1.0
References: <c9e1d356-2f28-e82f-d021-5331e2fc366d@danielfett.de> <CAP=vD9uLY6jissAZaEcEYLW2xNAr1NFgz7aO_NAjtuhs-C2pPA@mail.gmail.com> <CAJot-L1AH-_bHtvwPyiJSnW5AfpDTYHwOki1a3Lfc2iLCue5=g@mail.gmail.com> <ddaca239-fd96-4116-f607-821fdd2d9ee7@danielfett.de>
In-Reply-To: <ddaca239-fd96-4116-f607-821fdd2d9ee7@danielfett.de>
From: Warren Parad <wparad@rhosys.ch>
Date: Wed, 02 Mar 2022 18:29:28 +0100
Message-ID: <CAJot-L0vqZEaj3f1BJ9p2TmgBkv7fB8qDPLVWfwxb-Lmuw=Z6A@mail.gmail.com>
To: Daniel Fett <fett@danielfett.de>
Cc: Sascha Preibisch <saschapreibisch@gmail.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004e5d1205d93fa00b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hbtW3zWdRumKE0CBDb5FDBWnoNE>
Subject: Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2022 17:29:46 -0000

>
> I like the idea of a machine-readable feature support document...
> discovering those documents might still be a problem, though.


Yay! I don't think it is hard to build a bot to iterate github/github and
pull these. It gives us a starting point for how to attack this problem.

The key components would be:

   - OAuth WG defines what the existing features are - is this even
   possible?
   - We would have to keep track of those and make sure that list is up to
   date (we already do this for existing discovery documents), is this a
   burden for us?
   - ....
   - Profit

I think tools like openapi.tools would start to pop up, and places like
oauth.net could choose to host this.

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 6:11 PM Daniel Fett <fett@danielfett.de> wrote:

> Hi Warren,
> Am 02.03.22 um 17:05 schrieb Warren Parad:
>
> I don't think flooding this thread with random libraries is going to
> benefit anyone, so let's not do that.
>
> I agree, and that was not the aim of my question.
>
>
>
> 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.
>
> I'm not suggesting that we build any libraries, that would be a bad idea.
> I'm not so sure on curated lists, however.
>
>
>
>    - 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.
>
> I think that this goes into a completely wrong direction. Authorization
> servers should never be built towards certain libraries, in an ideal world
> at least. Also, why would I as an API provider even have to know about the
> SDKs? If my API follows the rules, any client library that follows the same
> rules should work.
>
>
>
>    - 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.
>
> I like the idea of a machine-readable feature support document...
> discovering those documents might still be a problem, though.
>
>
> *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.
>
> I don't think that a library which supports only selected scenarios (e.g.,
> a mobile app on Android) is a problem, as long as that is well documented.
>
> Also, I wouldn't expect the same library API for each library to make them
> exchangeable. They don't need to be interchangeable, because that would
> mean that somebody is doing the same work as someone else.
>
>
>
> 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.
>
> I'm not sure I'm following your thoughts here... could you please expand
> on that?
>
>
>
> 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.
>
> I agree that the problem space is different for servers than it is for
> clients. Let's focus on clients in this thread.
>
>
>
> 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.
>
> Machine clients might need to use MTLS, DPoP, or something similar. There
> is value in a library for machine clients as well. And since this use case
> is often more or less a subset of interactive clients, I would expect that
> most libraries will support both anyway.
>
>
>
> 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.
>
> That's why I'm advocating for a profile that covers many use cases. If I
> can tell a developer to go and find a library that supports
> OAuth-Modern-Feature-Set®, and it would be common for libraries to
> advertise their support for that, the problem would be much smaller.
>
> -Daniel
>
>
>
> - 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 <saschapreibisch@gmail.com>
> 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 <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 <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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> -- https://danielfett.de
>
>