OPDS Authentication - opds://authorize/ is not a valid value on Google

[gotson]

When trying to add opds://authorize/ for a Google OAuth2 client, this is not valid:

[HadrienGardeur]

Hello @gotson,

I'm not surprised that this is rejected by Google as it's clearly not as secure as what they would typically expect.
Although Google mentions URIs in this screenshot, my guess is that they only expect URLs to be documented in this field.

What's your use case for using Google as an OAuth provider here?

[gotson]

What's your use case for using Google as an OAuth provider here?

Social login.

[HadrienGardeur]

For social login, you usually want to log into another service using Google and Apple these days.

If your service is example.com, you could set up Google and Apple specific redirect URIs such as example.com/callback/google and example.com/callback/apple.

Once Google or Apple have returned their respective Access or Refresh tokens, your service can authenticate the user and then return an Access Token through the OPDS callback.

[gotson]

If your service is example.com, you could set up Google and Apple specific redirect URIs such as example.com/callback/google and example.com/callback/apple.

Once Google or Apple have returned their respective Access or Refresh tokens, your service can authenticate the user and then return an Access Token through the OPDS callback.

What you are referring to is that the OPDS server should also act as an OAuth2 Authorization server in a sense, in addition to being a Resource Owner.

There are existing pass through to Oauth2, for instance Komga uses OAuth2 login provided by Spring Security, where the redirect is driven by the server, but once the authentication is done, there is no need to return an Access Token. Instead, a classic session ID is returned via cookies.

Implementing the Authorization Server part is constraining.

[HadrienGardeur]

What you are referring to is that the OPDS server should also act as an OAuth2 Authorization server in a sense, in addition to being a Resource Owner.

Yes, that's what the Authentication for OPDS draft was designed for. It's mostly used by public and academic libraries right now, where the user is a library patron and uses a library card to authenticate.

Instead, a classic session ID is returned via cookies.

Some catalogs return a session using cookies as well, but ideally you want to have a:

• long lived Refresh Token that you can use only once (using the Refresh Token issues a new one)
• and a short lived Access Token

This is optimal for avoiding attacks where one of these tokens is intercepted and re-injected back.