Follow up of yersteday discussion on IRC:

olasd (@freenode_olasd:matrix.org): isn't direct grant basically bypassing the idea of a SSO (i.e. of a single trusted server handling credentials) by proxying the credentials through the authenticating app?
and of course [phabricator rant deleted]
anlambert: olasd: yes direct grant is exactely that, using an auth token is more secure as you don't need to proxy the credentials from django backend to keycloak
zack (@freenode_zack:matrix.org): anlambert: olasd: i'm unable to comment on whether direct grant would be appropriate here, but if it is, consolidating deposit usenames/passwords in the same auth DB where we have other stuff seems like a good thing
olasd (@freenode_olasd:matrix.org): zack: direct grant almost nullifies the "authentication hardening" properties of a (properly implemented) SSO system, so it's almost never appropriate (IMO)
(so it should only be used 1/ as a very last resort; 2/ and only enabled for a specific subset of apps and users that can't do better)
(because, basically, any credentials used in a direct grant flow should be considered tainted)
I totally agree with the premise of consolidating user authentication; but we need to do that carefully and avoid taking shortcuts

This makes me think about that the Direct Grant flow is what is currently used to
generate bearer tokens from the User profile Web UI in swh-web.

I was not a big fan of that solution but did not manage at the time to request an
OIDC offine_access scope, needed to generate long-lived tokens that can be used
to authenticate a user whithout having to use login/password credentials, using
the more secured OIDC Authorization Code flow.

Keycloak documentation does not mention any kind of restriction regarding the
authentication flow that can be used when requesting an offline_access so I must
have missed something while I was implementing the tokens generation UI.

Turns out I was not passing the scope query parameter to the right
OIDC URL while I was trying to use the Authorization Code flow during
my tests a couple of months ago ... So hopefully, using that more secured
authentication flow is totally feasible to generate a bearer token.

So instead of using the OIDC Direct Grant flow to generate bearer tokens
for Web API authentication, use the more secured Authorization Code
flow (as in webapp login) to avoid proxying SSO credentials from django
backend to Keycloak server.

This means no more SSO password will be asked in the Web API tokens
generation UI and a redirection to Keycloak login page will be made
to enter them.

Also as a consequence, previously stored encrypted tokens in webapp database
has to be removed as the encryption scheme has changed.
Hopefully, there is currently only a couple in production database generated
by swh staff members so the impact will be quite limited.
This does not mean the generated tokens so far will become invalid,
simply that they could not be displayed anymore in the Web UI.
I will send a mail to swh-devel mailing list to inform about that change.