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 <f...@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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
