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

[Daniel Fett <[e-mail]>]

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
>       o Mobile app clients for each of the app os, and further for
>         each of the app development frameworks
>       o Web apps
>       o Desktop apps
>   * There are OAuth machine clients
>       o BFF oauth code exchange clients
>       o client credentials clients
>       o third party machine clients
>       o leaf clients that need to validate authorization tokens
>       o [One caveat to this is that these can and will be written in
>         every possible language available]
>   * There are OAuth Authorization servers
>       o Open source ones
>       o SaaS models
>       o AS in a container
>       o embedded cloud native solutions
>       o 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 
> <[e-mail]> 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 <[e-mail]> 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
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/oauth
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/oauth
>
-- 
https://danielfett.de