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

From: Daniel Fett <[email-masked]>
Date: Tue, 1 Mar 2022 18:18:02 +0100

**

*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

---

From: Sascha Preibisch <[email-masked]>
Date: Wed, 2 Mar 2022 07:31:43 -0800

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-masked]> 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
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Warren Parad <[email-masked]>
Date: Wed, 2 Mar 2022 17:05:22 +0100

I don't think flooding this thread with random libraries is going to
benefit anyone, so let's not do that.

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.
   - 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.
   - 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.

*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.

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.

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.

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.

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.

- 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-masked]>
wrote:

> It can be deployed as a standalone service or be used as a side-car next
> to other docker containers in the same network.
>

---

From: Joseph Heenan <[email-masked]>
Date: Wed, 2 Mar 2022 16:23:35 +0000

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 <[email-masked]> 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. 
> 
>  * They are not well documented (e.g., it is often unclear which specifications are supported)
>  * 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. 
> 
>  * 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
> [email-masked]

---

From: Daniel Fett <[email-masked]>
Date: Wed, 2 Mar 2022 18:11:12 +0100

Hi Warren,

> benefit anyone, so let's not do that.

I agree, and that was not the aim of my question.

> dissect it a bit first. Who is struggling with "OAuth libraries" and 
> what is even the responsibility of one of them.
>
>   * 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.

>   * 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
>
> 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?

> 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 
> 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

> On Wed, Mar 2, 2022 at 4:33 PM Sascha Preibisch 
> <[email-masked]> wrote:
>
>     Hello Daniel!
>
>     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
>
>         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.
>
>
>         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.
>
>
>          * 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.
>
>
>         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
>
-- 
https://danielfett.de

---

From: Warren Parad <[email-masked]>
Date: Wed, 2 Mar 2022 18:29:28 +0100

> 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

On Wed, Mar 2, 2022 at 6:11 PM Daniel Fett <[email-masked]> wrote:

> I'm not suggesting that we build any libraries, that would be a bad idea.
> I'm not so sure on curated lists, however.
>
>
>
> 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.
>
>
>
>       - Mobile app clients for each of the app os, and further for each
>       of the app development frameworks
>       - Web apps
>       - Desktop apps
>       - [One caveat to this is that these can and will be written in
> 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.
>
>
>
> these will be wrapped by brand specific implementations so that careful
> 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
> 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.
>
>
>
>> 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

---

From: David Waite <[email-masked]>
Date: Fri, 4 Mar 2022 15:29:46 -0700

> On Mar 1, 2022, at 10:18 AM, Daniel Fett <[email-masked]> wrote:
> 

I’d argue this point - it is not easy to implement. It is far easier to describe.

The separation between codes, refresh and access tokens means that you have logic from a library being integrated at multiple levels, from API access to persistence to user presentation. There are also complexities that arise - any API call could require changes to persistence or new user interaction.

Because of the variability in the kinds of applications which could be supported, many libraries wind up looking like simple message object builders, with complex state and processing mechanisms underneath that do not necessarily map at all into the application architecture. On top of this you have to extend your own app with the communication and asynchronicity required.

>   * 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

I find the OAuth Server Metadata response to be a good format for the server configuration (even if not hosted via well-known, or if it is client-specific), and the client metadata from RFC 7591 to be a good start.

<snip>

> What can we do about this?

<snip>

>  * 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…

I would suspect it would be adding more constraints to profile behavior (beyond what we have done already in say the Security BCP) and then having tooling and conformity assessments based on that profile. My scope suspicion is that tooling and testing would be external.

<snip>

>  * 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 libra…

The only wrinkle I would add is that pre-established clients may have per client AS metadata, but the AS metadata format itself (e.g. JSON with specific keys) is still useful for representing that in a consistent manner as a format (rather than an endpoint). I have seen some slight extensions there, such as a parameter to provide JWK information inline.

Client metadata is harder, as there may be information in both the request and response that needs to be understood, as well as local configuration and secrets (such as private keys). There is also a chance for reproduction as well as uncaught differences when supporting multiple distinct AS as a client.

-DW