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

David Waite <david@alkaline-solutions.com> Fri, 04 March 2022 22:29 UTC

Return-Path: <david@alkaline-solutions.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 48F5E3A111D for <oauth@ietfa.amsl.com>; Fri, 4 Mar 2022 14:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 yRKy5XPBPjtT for <oauth@ietfa.amsl.com>; Fri, 4 Mar 2022 14:29:51 -0800 (PST)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41173A0443 for <oauth@ietf.org>; Fri, 4 Mar 2022 14:29:51 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 3515E20AA00; Fri, 4 Mar 2022 22:29:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1646432988; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BTU9+6KoHRkqyUaw6fz0CZvb7+aLPgrsnTWEbFDJGa8=; b=lGaLjhJZnKNmIKiBuo2mBk3DY43orBecfC6JVXwfL6IeD5S33kbbry6hVRuG929bRqF8gt C3OJ/V6J27VhcMeXwlusi+2LYz6o0AjpfV6VQumJSVB6Q7BSPy3vgW0g2Exn306962loLD CFjUhYLXSKVVUl4ZuWuWj//zGNm5Afk=
From: David Waite <david@alkaline-solutions.com>
Message-Id: <2B67EB69-3145-49BF-A209-A6EAD5BE9726@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E77655AD-DCE6-4414-941C-14E7BD0BE53B"
Mime-Version: 1.0
Date: Fri, 04 Mar 2022 15:29:46 -0700
In-Reply-To: <c9e1d356-2f28-e82f-d021-5331e2fc366d@danielfett.de>
Cc: oauth <oauth@ietf.org>
To: Daniel Fett <fett@danielfett.de>
References: <c9e1d356-2f28-e82f-d021-5331e2fc366d@danielfett.de>
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7M3VHACD17i91mAPhWPIPSwJkDY>
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: Fri, 04 Mar 2022 22:29:58 -0000

> On Mar 1, 2022, at 10:18 AM, Daniel Fett <fett@danielfett.de> wrote:
> 
>  * 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.

I’d argue this point - it is not easy to implement. It is far easier to describe.

The separation between codes, refresh and access tokens means that you have logic from a library being integrated at multiple levels, from API access to persistence to user presentation. There are also complexities that arise - any API call could require changes to persistence or new user interaction.

Because of the variability in the kinds of applications which could be supported, many libraries wind up looking like simple message object builders, with complex state and processing mechanisms underneath that do not necessarily map at all into the application architecture. On top of this you have to extend your own app with the communication and asynchronicity required.

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

I find the OAuth Server Metadata response to be a good format for the server configuration (even if not hosted via well-known, or if it is client-specific), and the client metadata from RFC 7591 to be a good start.

<snip>

> What can we do about this?

<snip>

>  * 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.

I would suspect it would be adding more constraints to profile behavior (beyond what we have done already in say the Security BCP) and then having tooling and conformity assessments based on that profile. My scope suspicion is that tooling and testing would be external.

<snip>

>  * 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. 

The only wrinkle I would add is that pre-established clients may have per client AS metadata, but the AS metadata format itself (e.g. JSON with specific keys) is still useful for representing that in a consistent manner as a format (rather than an endpoint). I have seen some slight extensions there, such as a parameter to provide JWK information inline.

Client metadata is harder, as there may be information in both the request and response that needs to be understood, as well as local configuration and secrets (such as private keys). There is also a chance for reproduction as well as uncaught differences when supporting multiple distinct AS as a client.

-DW