Keycloak: one login and one token issuer for all Pyronear services #23

Context & Objective

Authentication is handled separately in each service: the API has its own users and signs its own tokens, the platform and the annotator have their own login, and cameras use one-year tokens. Keycloak (OAuth2 / OIDC) would let us handle users, roles, password reset, MFA and SSO in one place, remove home-made security code, and answer what users and tenders ask for (it is common in professional and industrial information systems). Contributors are already working on it.

Objective: Keycloak becomes the single token issuer. The API, the platform, the annotator and the cameras only verify tokens.

What is done currently

• Dev environment: a Keycloak service for local dev is in progress (feat: add service keycloak pyro-envdev#45, open PR) with a fix for the local realm setup (fix(keycloak): complete local realm setup and health check pyro-envdev#50, open PR).
• Platform: a PR replaces the login with Keycloak (feat: replace auth with keycloak new-pyro-platform#295, open PR). Two older issues relate to the same topic: token lifetime and login method (As a user, when my token expire, i want to be notified new-pyro-platform#11, Camera support #12).
• API: the work is specified in two issues, users first (feat: Keycloak: Delegate user authentication to Keycloak (keep camera auth unchanged) pyro-api#698), then cameras (feat: Keycloak: Move camera authentication to Keycloak pyro-api#699). Nothing is merged yet.
• Annotator: open question about user login (Discussion: Keycloak for pyro-annotator authentication pyro-annotator#412). The annotator import will need Keycloak anyway, since access to the alert API will go through it.

What has to be done

One epic. Users (T4-26) and cameras (T1-27) are two phases, carried by the Period of each sub-issue. Sub-issues in each repo, in this order:

1. Dev environment (feat: add service keycloak pyro-envdev#45, #50): local Keycloak with a realm for tests, to build and test everything else.
2. Users (feat: Keycloak: Delegate user authentication to Keycloak (keep camera auth unchanged) pyro-api#698): the API verifies Keycloak tokens for users; users move to Keycloak; camera tokens stay as they are.
3. Platform (feat: replace auth with keycloak new-pyro-platform#295): OIDC login in the front; token expiry handled (As a user, when my token expire, i want to be notified new-pyro-platform#11).
4. Annotator (Discussion: Keycloak for pyro-annotator authentication pyro-annotator#412): decide the user login option; import through a Keycloak service account.
5. Production-ready Keycloak configuration (Keycloak configuration ready for production pi-manager-template#115): a config of Keycloak that can be deployed in production (database, backups, TLS, realm, upgrades).
6. Cameras (feat: Keycloak: Move camera authentication to Keycloak pyro-api#699, plus a companion issue Authenticate cameras with Keycloak (client credentials) pyro-engine#453; pyroclient lives in pyro-api/client and is part of feat: Keycloak: Move camera authentication to Keycloak pyro-api#699): client credentials per camera, replaced progressively on the fleet.
7. Rights built on top: roles by organisation, sites and livestream rights (a separate epic on sites, organisations and rights, to come).

Open questions

• Who operates the production Keycloak (database, upgrades, backups, TLS), and where does it run?
• Rollout for cameras: devices are updated progressively, so the API accepts both issuers for a while. How long?
• Intermittent 4G: what token lifetime, and how does a station behave when a refresh fails?
• Order with the Theodo hackathon (end of November): does the annotator need Keycloak before it?
• Existing accounts: one-shot migration script, and how users are told.

Done when

• Users of the platform, the API and the annotator log in through Keycloak
• The API no longer issues tokens and no longer stores users
• Cameras authenticate through Keycloak and tokens refresh without blocking local detection
• A production-ready Keycloak configuration exists in pi-manager-template, documented and backed up
• Linked sub-issues are closed in each repo

Theme Services · Priority P1 (high) · Period T4-26, T1-27