Protéger un site interne avec oauth2-proxy

Placez n'importe quel outil interne, tableau de bord ou site statique derrière le SSO Scrydon avec oauth2-proxy — sans modifier le code de l'application — en utilisant Scrydon comme fournisseur d'identité OIDC.

Vous avez un outil interne, un tableau de bord, un wiki ou un site statique que vous souhaitez placer derrière votre connexion Scrydon ? Vous n'avez pas besoin d'ajouter du code d'authentification. Placez oauth2-proxy devant et pointez-le vers votre fournisseur d'identité Scrydon. oauth2-proxy exécute la connexion OIDC, dépose son propre cookie de session sur le domaine de votre site et ne transmet que les requêtes des utilisateurs connectés — restreintes à qui vous autorisez (par exemple, tous les détenteurs d'un e-mail @votre-entreprise.com).

C'est le schéma standard « SSO pour un site qui n'a pas de SSO », et comme Scrydon est un fournisseur OIDC complet, la même approche fonctionne avec n'importe quel proxy compatible OIDC (Authelia, Pomerium, Traefik + oauth2-proxy, auth_request NGINX, …). Ce guide utilise oauth2-proxy.

oauth2-proxy dépose son propre cookie sur le nom d'hôte de votre site, donc cela fonctionne quel que soit le mode d'hébergement de Scrydon (routage par sous-chemin ou sous-domaine) et quel que soit le sous-domaine de votre site. Votre site ne voit jamais directement le cookie de session Scrydon.

Avant de commencer

Vous avez besoin de trois éléments depuis Scrydon :

Enregistrer un client confidentiel à portée organisation

Suivez Enregistrer un client OAuth (Mini App). Lors de la création, définissez :

Portée → Organisation · SSO uniquement. Votre passerelle ne fait que connecter les utilisateurs — elle n'appelle pas les API Scrydon, n'a donc besoin d'aucun espace de travail et obtient un seul client à l'échelle de l'organisation, restreint aux scopes d'identité (openid, profile, email).
Type de client → Confidentiel · secret client. oauth2-proxy s'exécute côté serveur et s'authentifie auprès du point de terminaison de jeton avec un client_secret.
URI de redirection → https://<votre-site>/oauth2/callback (le chemin de callback d'oauth2-proxy). Exemple : https://docs.internal.example.com/oauth2/callback.

Vous recevrez un ID client et un secret client.

Le secret client est affiché exactement une fois, juste après l'enregistrement — copiez-le immédiatement. Scrydon ne stocke qu'un hachage, il ne peut donc pas être récupéré plus tard. Si vous le perdez, utilisez Renouveler dans le panneau de détail de l'application pour en générer un nouveau (l'ancien secret cesse de fonctionner dès le renouvellement).

Copier votre URL de découverte

Ouvrez Paramètres → Plateforme → Identité et copiez l'URL de découverte OIDC. Elle ressemble à https://<votre-hôte-auth>/api/auth/.well-known/openid-configuration. oauth2-proxy n'a besoin que de l'issuer — c'est la même URL sans le suffixe /.well-known/openid-configuration, par ex. https://<votre-hôte-auth>/api/auth.

Copiez toujours l'hôte depuis l'onglet Identité — il est spécifique au tenant. Ne le devinez pas.

oauth2-proxy signe son propre cookie avec un secret qui doit faire exactement 16, 24 ou 32 octets :

openssl rand -base64 32 | head -c 32; echo

Configurer oauth2-proxy

oauth2-proxy se configure entièrement via des options ou des variables d'environnement OAUTH2_PROXY_*. La configuration OIDC minimale :

oauth2-proxy \
  --provider=oidc \
  --oidc-issuer-url="https://<votre-hôte-auth>/api/auth" \
  --client-id="<votre-id-client>" \
  --client-secret="<votre-secret-client>" \
  --redirect-url="https://<votre-site>/oauth2/callback" \
  --scope="openid email profile" \
  --email-domain="votre-entreprise.com" \
  --cookie-secret="<secret-de-cookie>" \
  --cookie-secure=true \
  --upstream="http://127.0.0.1:8080/" \
  --http-address="0.0.0.0:4180" \
  --reverse-proxy=true \
  --skip-provider-button=true

Options clés :

Option	Pourquoi
`--oidc-issuer-url`	L'issuer de votre URL de découverte. oauth2-proxy récupère tout le reste automatiquement.
`--redirect-url`	Doit correspondre exactement à l'URI de redirection de l'application enregistrée.
`--email-domain`	Liste d'autorisation. Répétez l'option (ou séparez par des virgules) pour plusieurs domaines ; `*` autorise tout utilisateur Scrydon connecté.
`--upstream`	Votre site/outil réel. oauth2-proxy fait office de reverse-proxy pour le trafic authentifié.
`--reverse-proxy=true`	À définir derrière votre propre ingress/load balancer pour que `X-Forwarded-*` soit de confiance.
`--skip-provider-button=true`	Va directement à la connexion Scrydon au lieu d'une page intermédiaire « Se connecter avec… ».

Pour restreindre à des personnes précises plutôt qu'à un domaine entier, supprimez --email-domain et utilisez --authenticated-emails-file=/chemin/vers/emails.txt (une adresse par ligne).

Déployer

Docker Compose

services:
  my-internal-site:
    image: my-internal-site:latest
    # aucun code d'auth nécessaire dans votre application

  oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy:v7.7.1
    command:
      - --provider=oidc
      - --oidc-issuer-url=https://<votre-hôte-auth>/api/auth
      - --client-id=<votre-id-client>
      - --client-secret=<votre-secret-client>
      - --redirect-url=https://docs.internal.example.com/oauth2/callback
      - --scope=openid email profile
      - --email-domain=votre-entreprise.com
      - --cookie-secret=<secret-de-cookie>
      - --cookie-secure=true
      - --http-address=0.0.0.0:4180
      - --reverse-proxy=true
      - --skip-provider-button=true
      - --upstream=http://my-internal-site:80/
    ports:
      - "4180:4180"

Pointez votre terminaison TLS / DNS pour docs.internal.example.com vers le port :4180 du conteneur oauth2-proxy.

Kubernetes (reverse-proxy devant un Service)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-site-oauth2-proxy
spec:
  replicas: 1
  selector:
    matchLabels: { app: my-site-oauth2-proxy }
  template:
    metadata:
      labels: { app: my-site-oauth2-proxy }
    spec:
      containers:
        - name: oauth2-proxy
          image: quay.io/oauth2-proxy/oauth2-proxy:v7.7.1
          args:
            - --provider=oidc
            - --oidc-issuer-url=https://<votre-hôte-auth>/api/auth
            - --redirect-url=https://docs.internal.example.com/oauth2/callback
            - --scope=openid email profile
            - --email-domain=votre-entreprise.com
            - --upstream=http://my-site.default.svc.cluster.local:80/
            - --http-address=0.0.0.0:4180
            - --cookie-secure=true
            - --reverse-proxy=true
            - --skip-provider-button=true
          env:
            - name: OAUTH2_PROXY_CLIENT_ID
              valueFrom: { secretKeyRef: { name: my-site-sso, key: client-id } }
            - name: OAUTH2_PROXY_CLIENT_SECRET
              valueFrom: { secretKeyRef: { name: my-site-sso, key: client-secret } }
            - name: OAUTH2_PROXY_COOKIE_SECRET
              valueFrom: { secretKeyRef: { name: my-site-sso, key: cookie-secret } }
          ports:
            - containerPort: 4180
---
apiVersion: v1
kind: Service
metadata:
  name: my-site-oauth2-proxy
spec:
  selector: { app: my-site-oauth2-proxy }
  ports:
    - port: 4180
      targetPort: 4180

Routez ensuite votre Ingress pour docs.internal.example.com vers le Service my-site-oauth2-proxy sur le port 4180 (au lieu de directement vers votre application). oauth2-proxy possède les chemins /oauth2/* et fait suivre tout le reste vers votre upstream une fois l'utilisateur authentifié.

Vérifier

Ouvrez https://docs.internal.example.com/ dans une session de navigateur vierge.
Vous devriez être redirigé vers votre connexion Scrydon.
Connectez-vous avec un compte autorisé → vous arrivez sur votre site.
Un compte hors de la liste d'autorisation est rejeté après connexion.

Dépannage

Symptôme	Cause / correction
`invalid_client` à l'écran de connexion	L'ID client/le secret ne correspondent pas à une application enregistrée, ou le secret a été renouvelé depuis la configuration du proxy.
Boucle de redirection vers la connexion	`--cookie-secure=true` mais le site est servi en HTTP simple, ou TLS n'est pas terminé devant oauth2-proxy. Servez en HTTPS.
Erreur de non-correspondance `redirect_uri`	`--redirect-url` doit être strictement identique à l'URI de redirection de l'application, y compris le schéma et le chemin `/oauth2/callback`.
Rejeté juste après la connexion	L'e-mail du compte n'est pas dans `--email-domain` / le fichier d'e-mails autorisés.
`cookie secret … must be 16, 24, or 32 bytes`	Régénérez le secret de cookie à exactement 32 octets.
Rejet « email not verified »	L'e-mail du compte n'est pas vérifié. Vérifiez-le, ou (assurance moindre) ajoutez `--insecure-oidc-allow-unverified-email=true`.

Protéger un site interne avec oauth2-proxy

Sur cette page