# 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**) et le **proxy** vers les micro-services du monorepo avec leurs **jetons techniques**.

- 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 l’amont avec le **Bearer de service** ou la **clé API** attendue par chaque cible.

Les appels **machine à machine** sans contexte utilisateur (scripts, `ia_dev`) restent possibles **en direct** vers chaque service, comme avant : la passerelle est une **option** pour les parcours « utilisateur authentifié par docv ».

## 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`. Les variables d’environnement sont les mêmes que pour le reste de la plateforme ([`config/services.local.env.example`](../../config/services.local.env.example)).

## 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é.

## Documentation détaillée

- [API/sso-gateway-api.md](../API/sso-gateway-api.md)
- [services/smart-ide-sso-gateway/README.md](../../services/smart-ide-sso-gateway/README.md)