Hi Daniel I do think it’s a problem that’s worth addressing somehow.
I think there’s another factor, which is that the providers of OAuth2 Authorization Servers (where they don’t have their own SDKs specific to their server) tend to lead the developer through how to do a “from scratch” implementation of OAuth2 and rarely if ever mention any libraries. (So a chicken and egg problem, because as you note there are languages without obvious good libraries to point people at.) There’s even a set of documentation I’ve seen that links to an online PKCE generator and appears to imply that the developer should just generate the values once and hardcode them into every request… I agree that pushing AS metadata will help matters. One of the downsides of maintaining OAuth2 libraries is dealing with constant “bug” reports when the library appears to a naive developer not to work correctly with a particular provider. I’ve found https://jwt.io/libraries <https://jwt.io/libraries> a very useful reference for JWT libraries; anything of a similar nature for OAuth libraries sounds good to me. Joseph > On 1 Mar 2022, at 17:18, 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), 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 > <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
