# Passerelle SSO — accès utilisateur aux API `smart_ide`

## Rôle

Le service **`smart-ide-sso-gateway`** (`services/smart-ide-sso-gateway/`) centralise la **validation OIDC** (jeton utilisateur émis par **docv / Enso**) puis délègue le **proxy HTTP** au service **`smart-ide-global-api`** (`services/smart-ide-global-api/`), qui applique les **jetons techniques** vers chaque micro-service.

- Le **navigateur** ou un **BFF** présente un `access_token` utilisateur (`Authorization: Bearer`).
- La passerelle vérifie la signature (**JWKS**), `iss`, éventuellement `aud`, puis appelle **smart-ide-global-api** avec `GLOBAL_API_INTERNAL_TOKEN` et propage `X-OIDC-Sub` / `X-OIDC-Email` pour les journaux et règles amont.

Les micro-services **n’implémentent pas le SSO** ; ils écoutent en **local** (`127.0.0.1`) avec authentification par jeton de service. Les appels **machine à machine** sans contexte utilisateur (scripts, `ia_dev`) peuvent toujours cibler **directement** un micro-service ou, pour un seul point d’entrée technique, **smart-ide-global-api** avec le Bearer interne.

## Lien avec docv / Enso

Le flux **authorization code + PKCE** et le rôle d’**IdP** restent décrits dans [sso-docv-enso.md](./sso-docv-enso.md). La passerelle ne remplace pas docv : elle **consomme** les `access_token` déjà obtenus par le front ou un back de confiance.

## Amonts proxy

Les clés exposées par `GET /v1/upstreams` et utilisées dans `/proxy/<clé>/...` sont : `orchestrator`, `repos_devtools`, `ia_dev_gateway`, `anythingllm_devtools`, `tools_bridge`, `langextract`, `regex_search`, `claw_proxy`, `local_office`. La résolution des URL et jetons par clé est implémentée dans **smart-ide-global-api** ; fichier d’exemple agrégé : [`config/services.local.env.example`](../../config/services.local.env.example).

**Journaux** : `.logs/sso-gateway/access.log` (passerelle) et `.logs/global-api/access.log` (agrégateur), lignes JSON par requête (hors `GET /health` pour l’API globale ; hors `GET /health` et `OPTIONS` pour le SSO).

## En-têtes vers l’amont

En plus de l’authentification de service, la passerelle peut envoyer :

- `X-OIDC-Sub` — claim `sub` du JWT utilisateur ;
- `X-OIDC-Email` — claim `email` si présent.

Les services amont peuvent s’en servir pour du **journal** ou des **règles fines** ; la **politique d’autorisation** métier reste de leur responsabilité.

## Comptes, projets et bases métier

La passerelle **ne conserve pas** de comptes utilisateurs, de profils projet, ni de quotas métier : elle ne fait que **vérifier** le JWT OIDC et **relayer** vers **smart-ide-global-api**, qui applique les jetons techniques et proxifie vers chaque micro-service.

Les **comptes**, droits par **projet**, abonnements, historiques et toute persistance **métier** liée à l’identité restent dans les **bases des applications** (ex. docv, Enso, autres produits) et dans leurs schémas de données — pas dans `smart-ide-sso-gateway`. Le découpage par projet côté IDE et chemins de déploiement est décrit sous `projects/<id>/conf.json` — [repo/projects-directory.md](../repo/projects-directory.md).

Les services amont qui reçoivent `X-OIDC-Sub` / `X-OIDC-Email` sont responsables de **résoudre** l’utilisateur vers un contexte projet via **leurs** API et bases.

## Documentation détaillée

- [API/sso-gateway-api.md](../API/sso-gateway-api.md)
- [API/global-api.md](../API/global-api.md)
- [packages/smart-ide-upstreams/README.md](../../packages/smart-ide-upstreams/README.md) — clés d’amont partagées (`@4nk/smart-ide-upstreams`)
- [services/smart-ide-sso-gateway/README.md](../../services/smart-ide-sso-gateway/README.md)
- [services/smart-ide-global-api/README.md](../../services/smart-ide-global-api/README.md)