OpenID-connect only support authorization code flow

[raffis]

Describe the change

Balloon already has a working Idp (see current situation). But 1st party apps like the web ui and the desktop client use the resource owner grant flow for internal authentication. The web ui uses the implicit flow for external OpenID-connect providers.

In the view of the desktop client this brings the issue that additional openid-connect providers have to be configured locally on each client (or create a custom build and ship the configuration). New auth possibilities are therefore hard to deploy afterwards. This also applies to the web client but the configuration is centralized.

This issue proposes that balloon should continuing shipping an Idp but unlike having support for the resource owner grant flow only the authorization code flow (with PKCE) should be supported and first party clients like the web client and the desktop client should also use this flow and behave like a 3rd party. This means that the balloon server or an additional micro service must implement the authentication process and a login form. There will be no login form on either the web client and the desktop client. Both clients (and any other client) will start the code authorization flow.

This solves multiple issues:

• Desktop clients do not need to be shipped with any custom authentication providers or any other custom authentication config.
• No implicit auth in the web client for 3rd party oidc providers (No redirection after the access token has expired)
• [Security] No support for the resource owner grant flow anymore which is a security issue. Clients can safely be used in 1st party apps without a secret using PKCE and the code authorization flow.
• This also means that the desktop and web client only need to implement AppAuth-js and OpenID-connect code authorization flow and nothing else.

Current situation

Currently balloon implements the following apps which are related to oauth2:

• Balloon.App.Idp Implements OpenID-connect protocol including support for google authenticator.

• Balloon.App.Webauthn Support for Webauthn in combination with Balloon.App.Idp.

• Balloon.App.Recaptcha Anti Bruteforce mechanism.

Should

Balloon must ship an idp with login support via a web form.

• Ship an Idp with a login form at /login
• Remove login forms from both clients and only implement the code authorization flow
• The balloon IdP should be open to customization meaning as it is the case now in both clients it should be possible to add 3rd party openid-connect providers.
• The whole Idp may be implemented as an own app/docker image.

Note: Balloon needs to continue support basic auth for protocols like WebDAV. Users authenticated via a 3rd party authentication provider still need to set a local balloon password to be able to use protocols like WebDAV.

Additional context

It would be nice we could use a service like dex but I see multiple issues here:

• How to handle local users, password changes, etc? Probably need to implement a custom connector
• There is no support for Webauthn yet
• There is no support for Two factor authentication like google authenticator (But planned, see here)
• Dex has only support for sql databases. Isn't really a problem but an additional container just for dex seems a bit overkill since balloon runs with MongoDB.

Balloon already has implemented those features and switching to dex still would be nice but feels like a step backwards.

[raffis]

Ory hydra might be a good solution where one can implement its own consent app. The disadvantage is that it has no MongoDB support and would require a separate db (postgres).