OPDS Authentication with OAuth2

[gotson]

Hello,

it seems OAuth2 in the OPDS Authentication is solely geared as a replacement for basic auth. It seems there is an assumption that when both Basic Auth and OAuth2 are available, the client should use OAuth2 (this is what Aldiko does).

This assumes that both authentication scheme are available for all users, which is not necessarily true.

These days, OAuth2 is mostly used for social login, and thus not all users may have enrolled into social login.

For instance Komga server can be configured with any OAuth2 provider, and users can decide how they want to login. Here is an example with both Google and Github configured as OAuth2 proviers:

IMHO the OPDS Authentication document should provide hints for the client on how to use the different flows. Examples could be:

• prefer this OAuth2 flow to Basic Auth if possible
• offer a choice to the user between those flows (could be basic auth, OAuth2 Google, OAuth2 Github for example)

There are also limitations on the OAuth2 capabilities, as highlighted in #75, but also because Implicit flow is not recommended anymore, see https://blog.postman.com/pkce-oauth-how-to/. This is an issue for Github for instance, which needs PKCE: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#web-application-flow

[HadrienGardeur]

Hello @gotson,

it seems OAuth2 in the OPDS Authentication is solely geared as a replacement for basic auth. It seems there is an assumption that when both Basic Auth and OAuth2 are available, the client should use OAuth2 (this is what Aldiko does).

It's slightly more complicated than that IMO:

• while Resource Owner Password Credentials Grant is very much a replacement for Basic Auth, that's not really the case of Implicit Grant which allows very different use cases
• that said, it's true that Aldiko (and probably other clients as well) can make the assumption that Resource Owner Password Credentials Grant is more secure than Basic Auth

These days, OAuth2 is mostly used for social login, and thus not all users may have enrolled into social login.

It's the most popular use case, but I wouldn't say that this is the only one, far from it. Many organizations who have a mobile app also use OAuth for managing authorization between their mobile app and their server for instance.

MHO the OPDS Authentication document should provide hints for the client on how to use the different flows. Examples could be:

• prefer this OAuth2 flow to Basic Auth if possible
• offer a choice to the user between those flows (could be basic auth, OAuth2 Google, OAuth2 Github for example)

I think that's something worth discussing within the OPDS community and there are many way we could approach this problem:

• provide guidance in the specification
• allow the expression of a preference in the Authentication Document

I'll reply to #75 separately because I think this affects your perception of this issue.

That said at the end of the day, we cannot decide on behalf of applications. They'll always be free to prefer one flow over another one for example. Apps are also likely to only support some of these flows rather than all of them, which might impact the way they handle them.

[…] but also because Implicit flow is not recommended anymore, see https://blog.postman.com/pkce-oauth-how-to/. This is an issue for Github for instance, which needs PKCE: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#web-application-flow

We definitely need to review our support for various grant types now that OAuth 2.1 has been published. I would put Authorization Code Grant with PKCE at the very top of the list of grant types that we should consider.

The most difficult part will remain striking a balance between security and support for a fully decentralized ecosystem though. There's an assumption with most OAuth 2.x grant types that the client and server know each other, which implies registering the client before any interaction can happen.

IMO, this is not compatible with a truly open and decentralized ecosystem for OPDS, which is what restricted the current draft to only two grant types. This is also why the current draft has to somehow twist Implicit Grant to make it work.