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

Sascha Preibisch <saschapreibisch@gmail.com> Wed, 02 March 2022 15:32 UTC

Return-Path: <saschapreibisch@gmail.com>
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 44BAE3A0A27 for <oauth@ietfa.amsl.com>; Wed, 2 Mar 2022 07:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=gmail.com
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 ccN4efW_MfUM for <oauth@ietfa.amsl.com>; Wed, 2 Mar 2022 07:31:57 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 166613A0A79 for <oauth@ietf.org>; Wed, 2 Mar 2022 07:31:57 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id u20so3482200lff.2 for <oauth@ietf.org>; Wed, 02 Mar 2022 07:31:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LnXIJDk0VEAW28KX7ByZ7reJjKcklXcbprjWEism8KY=; b=Jmn+LGsql/1hUUy4+XZPaD4rF/NrEqEDdQvndTcNiN7K3uhU6HbQhXXHoOsQAQjXhZ mNemdHNh9XLQX9aWVwxp6N5hdO/yEPu/ZkHmmhKkuSIgDtAUevB5lx4SCQL9rjQfnm1H AP05vRIgdSRfN35GM6iYn/NOBVbx0ZO8wwXIdKHcI8frtFYdGBHYpmnT6a1xINQYwRlp iCzHJ8in7I+Agfdh3WQ5HQ8UrPvVzBGIxMzv9IbQetyXy1X0Pe648N4xyY59kJxzd9LI qt3xBhaWa8GvQFXcCrl67R7TRvLiEtHuIWmrP/pWxutlEd6oH2GUlzuDiuR6+Uky80pA 1pUw==
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=LnXIJDk0VEAW28KX7ByZ7reJjKcklXcbprjWEism8KY=; b=0kDx5RMNjy82gB6phSMkzVvhDw5M02TTudY4ZS0Wj8q3M+kF9n9o/25Gq+uvAZSLBx Q0HmcFnH2l8lq70g5GFGzxSp+fES0qBuU5V/HYSUp2kRFXZMgwcAOVPUVUmcMG9HmUze 31BHr3f/b7R+JwzMxQNoH6RPjFUWw2ObOXXgtxvF0J34ANqc+gNhevJghMmQYV5it8x7 Z1tjnCorml96BUms3K60xwBjPgoQ8RZp9EAwxjhKWgb1qHvzhUw7yg8mlKG+zndVVa2V W56JGh0Ev07qxdi5g2mwkR3EKD1KVe4rkryJk8ioY92IBDmHCnOyHJ/HeIjDThLL8lW3 Qinw==
X-Gm-Message-State: AOAM531xCiV3aZpYqFKqKWBOFitfvLrlIwMoMKVDMRYN9oV5SEnrxWVo 6g5DN54g+J1pyh437uqr7EcYsLbSMp38n2HdF8l1297h
X-Google-Smtp-Source: ABdhPJwF7h0VJVnNPFWuiPM88ucCOjAu4fv7RmoFhtK73teJc8unX2FcNPz64cmuTgUx2ZXLiTl2krA+InrQ4qAC00o=
X-Received: by 2002:ac2:5de4:0:b0:443:5b80:d4c4 with SMTP id z4-20020ac25de4000000b004435b80d4c4mr18656965lfq.373.1646235114842; Wed, 02 Mar 2022 07:31:54 -0800 (PST)
MIME-Version: 1.0
References: <c9e1d356-2f28-e82f-d021-5331e2fc366d@danielfett.de>
In-Reply-To: <c9e1d356-2f28-e82f-d021-5331e2fc366d@danielfett.de>
From: Sascha Preibisch <saschapreibisch@gmail.com>
Date: Wed, 02 Mar 2022 07:31:43 -0800
Message-ID: <CAP=vD9uLY6jissAZaEcEYLW2xNAr1NFgz7aO_NAjtuhs-C2pPA@mail.gmail.com>
To: Daniel Fett <fett@danielfett.de>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003caf3705d93dfb68"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/blJ9wb5I5UCI2pBO2mndIp4TpJg>
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 15:32:02 -0000

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
>