feat: Implement OIDC sign-in

[hangy]

What

The main aim is to use Keycloak as an IdP, and connect Product Opener as a RP. We want to move the basics of user management out of Product Opener.

In the future, this can be used as a base to enable #1204 to be implemented, even though it will probably not be part of the initial change as to not blow up the PR too much. One important requirement is to keep compatibility with the current Basic Auth mechanism.

Screenshot

TBD

Related issue(s) and discussion

• closes Implement a central User Service for auth - keycloak #1596

Adding a task list to track progress:

• @hangy: Move all interaction with user_emails.sto to call Keycloak APIs instead
• @john-gom: Move all read and write operations to user.sto files to one place
• Update user.sto read/write operations to get user "signup" fields from Keycloak (not required, as we want Keycloak as the canonical source)
• @hangy: Pass country / language to login page
• @hangy Add delete user event listener to Keycloak, trigger Redis event feat: Publish user deletion event to Redis openfoodfacts-auth#3
• @hangy Store deleted users in a table feat: Store deleted users in a table openfoodfacts-auth#14
• @hangy Redis event subscriber on Product Opener to remove user name from products (TBA extend to other applications) (WIP https://github.com/hangy/openfoodfacts-server/tree/keycloak-redis)
• @john-gom: Add all "signup" fields to Keycloak and import language and country lists from taxonomy json
• @john-gom: Fix locale pick list to be searchable
• Upgrade to 24.0.0 when available and check localization is working for account page
• Set up Crowdin translation project ci: Create crowdin.yml openfoodfacts-auth#2
• @hangy Test with Mobile and other API usage scenarios
  • Flutter app seems to work fine
  • Hunger games shows user logged in (with modified hunger games branch, as main currently has a lot of hard coded URLs)
  • Write test with robotoff not that easy in separate setup 😞
• @hangy Benchmark import of the number of users we have in production
  time ./scripts/migrate_users_to_keycloak.pl with around 400.000 synthetic accounts took about 45 minutes on my desktop PC in WSL2.

Save for a later phase:

• HOLD on this pending unification. Live with inconsistent passwords for now. Update OPF, OBF and OPFF to login via Keycloak and redirect to OFF for user account info
• Extend user attribute table to store more text
• Select correct language / country for user after login redirect back to OFF
  Example: If the users was on fr.openfoodfacts.org before signing up, and they change their locale to Spanish during registration in Keycloak, do we want them to be redirected to a Spanish page instead?
  Problem: Differentiating between first login (because of registration) and subsequent login would have to be done based on whether or not ${userid}.sto exists.
• Get Product Opener client to self register on initialization and store secret somewhere safe
  Advantage: The client secret does not have to be exposed to the admin. However, they'll have access to the secret anyways, unless we were to store the secret in some kind of HSM.
  Disadvantage: Some client configuration can be done during self-registration, but some necessary permissions like realm-management need to be configured manually by an admin, anyways.
• Get rid of user.sto files completely
  To consider: This file currently contains information about the users' active sessions. Do we want to replace the opaque session identifier by an encrypted cookie? Also, we need some kind of directory to identify users that have used ProductOpener know if we have to do something when a deletion event comes in through Redis. (Obviously, this could be done in MongoDB or PostgreSQL instead, but is there a huge difference?)
• Move API consumers to use client_credentials rather than login
• Update mobile app to use Keycloak web forms for login (eg. OIDC Authorization Code Flow)
• Figure out how/if org management should be done in Keycloak (Done in MongoDB)

Moved to openfoodfacts-auth:

• Create message files for all fields we will need translating Make sure all text we use is included in the message.properties files openfoodfacts-auth#33
• Finalize theming for all Keycloak screens that users will see Complete theming on all screens openfoodfacts-auth#31
• Configure signup / forgot password email in Keycloak Design email verification and password reset emails openfoodfacts-auth#32
• figure out security configuration for production deployment Hardening for production openfoodfacts-auth#34
• work out what to do about staging, e.g. share keycloak with production or have separate instances and maybe copy database across periodically Work out how to refresh staging from production openfoodfacts-auth#35
• Support social login providers Support social login providers openfoodfacts-auth#49
• Support passkeys Support passkeys openfoodfacts-auth#50

[hangy]

/update_tests_results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud