> > I like the idea of a machine-readable feature support document... > discovering those documents might still be a problem, though.
Yay! I don't think it is hard to build a bot to iterate github/github and pull these. It gives us a starting point for how to attack this problem. The key components would be: - OAuth WG defines what the existing features are - is this even possible? - We would have to keep track of those and make sure that list is up to date (we already do this for existing discovery documents), is this a burden for us? - .... - Profit I think tools like openapi.tools would start to pop up, and places like oauth.net could choose to host this. 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 6:11 PM Daniel Fett <[email protected]> wrote: > 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 > - Mobile app clients for each of the app os, and further for each > of the app development frameworks > - Web apps > - Desktop apps > - There are OAuth machine clients > - BFF oauth code exchange clients > - client credentials clients > - third party machine clients > - leaf clients that need to validate authorization tokens > - [One caveat to this is that these can and will be written in > every possible language available] > - There are OAuth Authorization servers > - Open source ones > - SaaS models > - AS in a container > - embedded cloud native solutions > - 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
