sng sso

Disponible

Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.

Le groupe sng sso vous identifie auprès de StackNGO : il obtient un jeton d'identité auprès du SSO de la plateforme (https://auth.dev.stackngo.app) et l'enregistre dans votre fichier de configuration. Ce jeton ne donne accès à aucun tenant : c'est sng tenant use qui l'échange ensuite contre une session de tenant.

sng sso login          # navigateur
sng sso whoami
sng tenant use acme

Le parcours complet est décrit dans Le modèle identité, session, tenant. Les flags globaux (--config, --json, -v, --version) sont décrits dans l'index de la CLI.

Commande	Route	Jeton présenté
`login`	SSO `…/login/oauth/authorize` et `…/api/login/oauth/access_token` ; avec `--oidc` : `POST /v1/iam/session`	—
`logout`	`POST /v1/iam/logout`	identité
`whoami`	`GET /v1/iam/me`	identité

Aucune de ces routes ne vérifie de policy.

sng sso login [--client-credentials [--client-id ID] [--client-secret SECRET]] [--oidc]

Trois modes, exclusifs :

Mode	Pour qui	Ce qui est enregistré
(défaut) navigateur, OAuth2 Authorization Code + PKCE	vous, sur votre poste	jeton d'identité (`access_token`, `refresh_token`)
`--client-credentials`	un script ou une CI, avec les identifiants de votre application machine (`IAMApplication`)	jeton d'identité (`access_token`)
`--oidc` Bêta	un runner CI persistant	une session de tenant (`tenant_token`) ; l'identité enregistrée est effacée

Flag	Type	Défaut	Description
`--client-credentials`	bool	`false`	flux machine `client_credentials` au lieu du navigateur
`--client-id`	string	(variable d'environnement, puis client de la CLI)	identifiant client de l'application machine, avec `--client-credentials` seulement ; à défaut `STNG_OAUTH_CLIENT_ID`, puis l'identifiant intégré à la CLI
`--client-secret`	string	(variable d'environnement)	secret client ; à défaut `STNG_OAUTH_CLIENT_SECRET`
`--oidc`	bool	`false`	échange le jeton OIDC du job CI contre une session de tenant et l'enregistre

Navigateur (PKCE)

La CLI ouvre un port local éphémère sur 127.0.0.1, imprime l'URL de connexion et ouvre votre navigateur dessus. Après connexion, le SSO redirige vers http://127.0.0.1:<port>/callback et la CLI échange le code contre les jetons (scopes openid profile email).

sng sso login

Ouvrez cette URL dans votre navigateur :
https://auth.dev.stackngo.app/login/oauth/authorize?client_id=…&code_challenge=…&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3A53817%2Fcallback&response_type=code&scope=openid+profile+email&state=…
session saved (api https://api.dev.stackngo.fr)

Sans navigateur graphique (serveur distant), ouvrez l'URL imprimée sur une machine qui peut joindre le port local de la CLI ; sinon, ouverture navigateur: … s'affiche et la commande attend. Le navigateur affiche Connexion réussie. Vous pouvez fermer cette fenêtre.

L'adresse du SSO et l'identifiant client de la connexion par navigateur sont intégrés au binaire : ni le fichier de configuration ni une variable d'environnement ne les changent.

`--client-credentials`

Connexion avec les identifiants d'une application machine déclarée par une IAMApplication au flux client_credentials :

sng sso login --client-credentials --client-id "$CLIENT_ID" --client-secret "$CLIENT_SECRET"
# ou, sans rien sur la ligne de commande :
STNG_OAUTH_CLIENT_ID="$CLIENT_ID" STNG_OAUTH_CLIENT_SECRET="$CLIENT_SECRET" sng sso login --client-credentials
sng tenant use acme

session saved (api https://api.dev.stackngo.fr)

L'identifiant client vient de --client-id, sinon de STNG_OAUTH_CLIENT_ID, sinon de l'identifiant intégré à la CLI. Ces deux réglages ne valent que pour --client-credentials : la connexion par navigateur garde toujours l'identifiant de la CLI. Pour que la machine ouvre ensuite une session de tenant, attachez-lui une policy avec assume-role (voir Machines et comptes de service).

Bêta

Fonctionnalité en cours de déploiement. L'interface décrite ici est celle de la prochaine livraison : elle peut encore évoluer, et n'est pas forcément activée sur votre tenant.

La fédération des pipelines CI est activée progressivement.

`--oidc` : runner CI persistant

Dans un job CI, aucune connexion n'est nécessaire : chaque commande de tenant détecte le jeton OIDC du job, ouvre une session en mémoire et la rouvre à l'expiration, sans rien écrire sur disque. sng sso login --oidc sert seulement quand plusieurs commandes ou scripts doivent partager une session enregistrée (runner persistant).

La commande lit le jeton du job, dans cet ordre :

Source	Variable
jeton fourni en variable (GitLab `id_tokens`)	`STNG_OIDC_TOKEN`
jeton dans un fichier	`STNG_OIDC_TOKEN_FILE`
GitHub Actions (`permissions: id-token: write`)	`ACTIONS_ID_TOKEN_REQUEST_URL` et `ACTIONS_ID_TOKEN_REQUEST_TOKEN`, audience `STNG_OIDC_AUDIENCE` (défaut : `https://api.dev.stackngo.fr`)

Puis elle appelle POST /v1/iam/session sur le tenant STNG_TENANT (à défaut le tenant courant), avec STNG_OIDC_TRUST si plusieurs trusts du tenant peuvent correspondre.

STNG_TENANT=acme sng sso login --oidc

OIDC session saved: tenant acme (token from STNG_OIDC_TOKEN, expires in 900s)

Sortie --json : {"tenant": "acme", "origin_tenant": "acme", "expires_in": 900, "source": "STNG_OIDC_TOKEN"}.

La session enregistrée ne se renouvelle pas : à l'expiration (au plus la maxSessionDuration du trust), relancez sng sso login --oidc. Le jeton d'identité enregistré est effacé, pour qu'une session OIDC ne soit jamais renouvelée avec l'identité d'un autre sujet. Une session enregistrée n'ouvre que les routes du tenant : sng tenant list, create, use et sng template exigent une identité.

Erreurs typiques

Message	Cause
`client_credentials requires --client-secret or STNG_OAUTH_CLIENT_SECRET`	`--client-credentials` sans secret
`--client-id only applies to --client-credentials`	`--client-id` donné sans `--client-credentials`
`client_credentials 401: …`	secret refusé par le SSO
`oauth error: access_denied (…)`	connexion refusée ou annulée dans le navigateur
`oauth state mismatch`	réponse du navigateur qui ne correspond pas à cette connexion : relancez
`binary has no embedded auth: …`	binaire compilé sans paramètres SSO : installez un binaire officiel
`--oidc and --client-credentials are mutually exclusive`	deux modes à la fois
`no CI OIDC token: set STNG_OIDC_TOKEN (GitLab id_tokens), STNG_OIDC_TOKEN_FILE, or run in GitHub Actions with permissions: id-token: write`	aucun jeton de job détecté
`OIDC: tenant required: set STNG_TENANT to the tenant the CI job authenticates to`	ni `STNG_TENANT` ni tenant courant
`OIDC exchange refused (401 invalid identity token): no trust of tenant "acme" accepts this CI token (iss=…, aud=…, sub=…); …`	aucun trust ne correspond, ou plusieurs : comparer avec `sng tenant oidc get`, ou fixer `STNG_OIDC_TRUST`
`jeton OIDC du CI expiré (CI OIDC token expired): …`	le jeton fourni par variable ou fichier a expiré
`api_url must be HTTPS (except localhost), got: …`	`STNG_API_URL` en `http://` vers un hôte distant

sng sso logout

sng sso logout

Met fin à toutes les sessions de tenant ouvertes avec votre compte, puis efface de la configuration le jeton d'identité, le jeton de rafraîchissement, la session et le tenant courant. La commande appelle POST /v1/iam/logout avec votre jeton d'identité ; si cet appel échoue (identité déjà expirée, réseau), la configuration locale est effacée quand même.

sng sso logout

signed out

Effet côté serveur

Toutes les sessions de tenant émises pour votre compte jusqu'à la déconnexion sont refusées (401) en quelques secondes, y compris celles copiées sur un autre poste. Votre jeton d'identité, lui, n'est qu'oublié localement : une copie de ce jeton reste valable jusqu'à son expiration et peut encore ouvrir une session. Voir Authentification de l'API.

sng sso whoami

sng sso whoami [--json]

Affiche l'identité connectée, telle que le SSO la décrit.

sng sso whoami

org=stackngo user=alice email=alice@acme.example platform_admin=false
roles: stackngo/dev

La ligne roles: n'apparaît que si vous portez des rôles.

Sortie --json :

{
  "organization": "stackngo",
  "username": "alice",
  "display_name": "Alice",
  "email": "alice@acme.example",
  "roles": ["stackngo/dev"],
  "is_platform_admin": false,
  "tenant": ""
}

Avec une session OIDC (CI) Bêta

Quand la CLI travaille avec une session sans identité (jeton OIDC du job détecté, session enregistrée par sng sso login --oidc, ou STNG_TENANT_TOKEN sans STNG_ACCESS_TOKEN), whoami décode la session au lieu d'appeler GET /v1/iam/me :

kind=oidc sub=acme/gitlab-deploy tenant=acme
name: project_path:acme/infra:ref_type:branch:ref:main
expires: 2026-10-07T10:42:00Z

Sortie --json : {"kind": "oidc", "sub": "acme/gitlab-deploy", "name": "…", "tenant": "acme", "origin_tenant": "acme", "expires_at": "…"}.

Erreurs typiques : not authenticated: run sng sso login or set STNG_ACCESS_TOKEN ; not authenticated: run sng sso login (identité expirée, 401).

Variables d'environnement

Variable	Effet
`STNG_ACCESS_TOKEN`	jeton d'identité à utiliser au lieu de celui du fichier
`STNG_TENANT_TOKEN`	session de tenant à utiliser ; prime sur la détection OIDC
`STNG_TENANT`	tenant courant
`STNG_OAUTH_CLIENT_ID`	identifiant client de `--client-credentials`
`STNG_OAUTH_CLIENT_SECRET`	secret de `--client-credentials`
`STNG_OIDC_TOKEN`, `STNG_OIDC_TOKEN_FILE`, `STNG_OIDC_AUDIENCE`, `STNG_OIDC_TRUST`	jeton OIDC du job CI et son usage (Bêta)

Liste complète dans Configuration.

Voir aussi

Guides : Le modèle identité, session, tenant, Machines et comptes de service, Déployer sans secret (OIDC)
Commandes voisines : sng tenant (use, assume), sng config
API : Authentification

sng sso login​

Navigateur (PKCE)​

--client-credentials​

--oidc : runner CI persistant​

Erreurs typiques​

sng sso logout​

sng sso whoami​

Variables d'environnement​

Voir aussi​

sng sso login