Staging instance, all changes can be removed at any time

Skip to content

auth: Generate bearer token using OIDC Authorization Code flow

Antoine Lambert requested to merge generated-differential-D4692-source into generated-differential-D4692-target

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.

Migrated from D4692 (view on Phabricator)

Merge request reports