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 >
- [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