# Authentification ArcadeOps

Les espaces de travail ArcadeOps sont isolés par organisation. L'interface web utilise Supabase Auth et le serveur MCP canonique utilise OAuth 2.0 avec PKCE.

Document canonique : https://arcadeops.leadalpes.fr/auth.md

## Quand utiliser ce parcours

Utiliser ce parcours OAuth pour connecter un client MCP à ArcadeOps. La consultation des documents
publics ne demande pas de jeton ; les outils et données d'une organisation restent protégés.

## 1. Discover / Découvrir la ressource protégée

- Ressource protégée : https://arcadeops.leadalpes.fr/.well-known/oauth-protected-resource/mcp
- Serveur d'autorisation : suivre l'URL déclarée dans `authorization_servers`, puis charger son
  document `/.well-known/oauth-authorization-server`
- Métadonnées du serveur d'autorisation actuellement déclaré :
  https://bnunkedencbjnrjapybz.supabase.co/auth/v1/.well-known/oauth-authorization-server
- Métadonnées client public : https://arcadeops.leadalpes.fr/api/v1/mcp/oauth/client-metadata

## 2. Pick a method / Choisir OAuth avec PKCE

Utiliser OAuth 2.0 Authorization Code avec PKCE S256. Le serveur produit n'accepte pas de clé API
dans une URL et le MCP public de découverte ne donne accès à aucune donnée de tenant.

## 3. Register / Enregistrer ou identifier le client

Le serveur d'autorisation publie son endpoint d'enregistrement dynamique. Les clients publics
utilisent `token_endpoint_auth_method=none` et déclarent exactement leurs URI de redirection.

## 4. Claim / Demander les capacités minimales

Choisir uniquement les scopes nécessaires au cas d'usage. Les capacités métier ArcadeOps restent
ensuite bornées par l'organisation, le rôle, les permissions et le niveau de risque du grant.

## 5. Construire la demande d'autorisation

Demander un code avec PKCE S256. Inclure un `state` imprévisible, l'URI de ressource MCP canonique et
uniquement les scopes nécessaires. Ne pas lancer le consentement dans une iframe.

## 6. Faire approuver le consentement

L'utilisateur s'authentifie, choisit l'organisation autorisée et confirme les capacités demandées.
ArcadeOps peut refuser un scope, une ressource ou une URI de redirection non conforme.

## 7. Échanger le code

Envoyer le code, le `code_verifier`, le client et la même URI de redirection au `token_endpoint`.
Conserver le jeton hors des prompts, URL, journaux et artefacts.

## 8. Use credential / Appeler le serveur MCP

Envoyer le jeton avec `Authorization: Bearer` vers https://arcadeops.leadalpes.fr/mcp. Commencer par
la négociation MCP et `tools/list`, puis appeler uniquement les outils couverts par le grant.

## 9. Renew and revoke / Renouveler et révoquer

Utiliser le `refresh_token` uniquement avec le `token_endpoint` annoncé. Révoquer l'accès depuis les
paramètres d'intégration ArcadeOps ou auprès du serveur d'autorisation, puis supprimer localement les
jetons du client. Ne jamais conserver un jeton révoqué comme mécanisme de reprise.

## 10. Errors / Erreurs structurées

Les capacités accordées sont liées au sujet OAuth, à son organisation et à la version du grant. Les lectures et écritures disponibles dépendent des capacités `arcadeops.*`, du rôle tenant et du plafond de risque. Une capacité d'écriture ne supprime jamais les validations humaines exigées par la politique de la Mission.

Envoyer le jeton uniquement dans l'en-tête `Authorization: Bearer`. Ne jamais placer un jeton dans une URL, un prompt, un log ou un artefact.

Un `401` avec `WWW-Authenticate` déclenche une nouvelle découverte ou reconnexion. Un `403` indique
que le jeton est valide mais que le tenant, le rôle ou la capacité ne permet pas l'action. Ne jamais
réessayer une mutation en boucle sans vérifier son identifiant d'idempotence et son état.