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
<[email protected]> 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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
https://danielfett.de
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
