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 > >
- [OAUTH-WG] OAuth: The frustrating lack of good li… Daniel Fett
- Re: [OAUTH-WG] OAuth: The frustrating lack of goo… Warren Parad
- Re: [OAUTH-WG] OAuth: The frustrating lack of goo… Sascha Preibisch
- Re: [OAUTH-WG] OAuth: The frustrating lack of goo… Joseph Heenan
- Re: [OAUTH-WG] OAuth: The frustrating lack of goo… Daniel Fett
- Re: [OAUTH-WG] OAuth: The frustrating lack of goo… Warren Parad
- Re: [OAUTH-WG] OAuth: The frustrating lack of goo… David Waite