Trois quickstarts, zéro verrou.
Obexal est un fournisseur OIDC et OAuth 2.1 complet : discovery, JWKS, PAR, introspection et révocation sont exactement là où les spécifications les placent. Commencez par trois quickstarts en curl, puis approfondissez dans la documentation.
Ajouter le login à une app web
Code d'autorisation avec PKCE (S256) : lisez le document de discovery, envoyez l'utilisateur vers l'endpoint d'autorisation, échangez le code.
# 1. Lire le document de discovery
curl -s https://accounts.obexal.com/.well-known/openid-configuration
# 2. Générer le verifier PKCE et son challenge S256
CODE_VERIFIER=$(openssl rand -base64 48 | tr -dc 'a-zA-Z0-9' | cut -c1-64)
CODE_CHALLENGE=$(printf '%s' "$CODE_VERIFIER" \
| openssl dgst -sha256 -binary | openssl base64 -A | tr '+/' '-_' | tr -d '=')
# 3. Envoyer l'utilisateur vers l'authorization_endpoint du document de discovery
# .../oauth/authorize?response_type=code&client_id=$CLIENT_ID
# &redirect_uri=$REDIRECT_URI&scope=openid+profile+email
# &code_challenge=$CODE_CHALLENGE&code_challenge_method=S256
# 4. Échanger le code reçu contre des jetons
curl -s https://accounts.obexal.com/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "grant_type=authorization_code" \
--data-urlencode "code=$AUTH_CODE" \
--data-urlencode "redirect_uri=$REDIRECT_URI" \
--data-urlencode "client_id=$CLIENT_ID" \
--data-urlencode "code_verifier=$CODE_VERIFIER"Protéger un service machine
Client credentials pour les appels de service à service. Le secret vient de votre environnement ou de votre gestionnaire de secrets, jamais en clair dans la ligne de commande.
# CLIENT_SECRET est injecté par votre gestionnaire de secrets, jamais saisi en clair
curl -s https://accounts.obexal.com/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "grant_type=client_credentials" \
--data-urlencode "client_id=$CLIENT_ID" \
--data-urlencode "client_secret=$CLIENT_SECRET" \
--data-urlencode "scope=directory.read"
# Réponse
{
"access_token": "eyJhbGciOiJSUzI1NiIs...",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "directory.read"
}Donner une identité à un agent IA
L'agent s'authentifie avec ses propres client credentials (PAR disponible sur /oauth/par). La délégation porte un nom précis : Token Exchange, RFC 8693. Le jeton émis trace la chaîne de délégation dans le claim act.
# 1. L'agent obtient son propre jeton, borné par son plafond de scopes et son TTL maximal
curl -s https://accounts.obexal.com/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "grant_type=client_credentials" \
--data-urlencode "client_id=$AGENT_CLIENT_ID" \
--data-urlencode "client_secret=$AGENT_CLIENT_SECRET" \
--data-urlencode "scope=crm.read"
# 2. La délégation, nommée correctement : Token Exchange (RFC 8693)
# L'agent agit au nom d'un utilisateur ; le jeton porte le claim act
curl -s https://accounts.obexal.com/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
--data-urlencode "subject_token=$USER_ACCESS_TOKEN" \
--data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
--data-urlencode "client_id=$AGENT_CLIENT_ID" \
--data-urlencode "client_secret=$AGENT_CLIENT_SECRET" \
--data-urlencode "scope=crm.read"Plafonds de scopes, kill switch et détection d'anomalies sont détaillés sur la page Identité des agents IA.
Valider un jeton
Validation locale avec les clés publiées quand la latence compte, introspection quand la révocation et le kill switch doivent être visibles immédiatement.
# Option A : validation locale avec les clés publiées
curl -s https://accounts.obexal.com/.well-known/jwks.json
# puis vérifiez signature, exp, iss et aud dans votre bibliothèque JWT
# Option B : introspection côté serveur (RFC 7662)
# Jetons révoqués et kill switch d'agent y sont visibles immédiatement
curl -s https://accounts.obexal.com/oauth/introspect \
--data-urlencode "token=$ACCESS_TOKEN" \
--data-urlencode "client_id=$CLIENT_ID" \
--data-urlencode "client_secret=$CLIENT_SECRET"Les endpoints en un coup d'œil
- Discovery
- /.well-known/openid-configuration
- JWKS
- /.well-known/jwks.json
- Token
- /oauth/token
- Pushed authorization requests
- /oauth/par
- Introspection
- /oauth/introspect
- Révocation
- /oauth/revoke
- Déconnexion RP-initiated
- /oauth/logout
- Userinfo
- /oauth/userinfo
- Métadonnées SAML
- /saml/idp/{tenant}/metadata
- Utilisateurs SCIM
- /scim/v2/Users
- Contrat API d'administration (OpenAPI 3.1)
- /v1/openapi.json
L'API d'administration est décrite par un contrat OpenAPI 3.1 public : générez un client dans votre langage plutôt que d'attendre un SDK.
Provisionner les utilisateurs en SCIM
Le SCIM 2.0 entrant couvre la ressource Users ; les groupes se gèrent dans l'annuaire Obexal. Le SCIM sortant provisionne vos apps aval, avec déprovisionnement automatique.
POST /scim/v2/Users HTTP/1.1
Host: accounts.obexal.com
Authorization: Bearer $SCIM_TOKEN
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "marie.durand@example.com",
"name": { "givenName": "Marie", "familyName": "Durand" },
"active": true
}Les agents IA, côté API d'administration
Tout ce qu'un agent fait au endpoint de token se gouverne depuis l'API d'administration.
Enregistrer un agent
Chaque agent reçoit ses propres client credentials, un propriétaire humain, une date d'expiration et des statuts de cycle de vie (actif, dormant, expiré, orphelin).
Plafonds fail-closed
Un plafond de scopes et un TTL maximal par agent : toute demande au-delà est refusée, jamais dégradée en silence.
Kill switch immédiat
Coupez un agent en un appel : les jetons déjà émis deviennent inertes à l'introspection. Les secrets se renouvellent et expirent selon le calendrier prévu.
Pratique, et honnête
Sandbox
L'essai gratuit fait office de sandbox : 30 jours, sans carte bancaire.
Statut du service
L'état du service est publié en continu.
Changelog
Chaque évolution notable de l'API et du produit est publiée.
SDK TypeScript
Un SDK TypeScript zéro dépendance existe, orienté navigateur. Côté serveur, l'API se consomme en HTTP depuis n'importe quel langage, ou via un client généré depuis le contrat OpenAPI.
FAQ développeurs
Quels types de grant sont pris en charge ?
Code d'autorisation avec PKCE (S256) pour les applications avec utilisateur, client credentials pour les services et les agents, et Token Exchange (RFC 8693) pour la délégation. Les Pushed Authorization Requests sont disponibles sur /oauth/par.
Comment authentifier un client confidentiel ?
Par client_secret ou par private_key_jwt. DPoP est pris en charge pour lier le jeton à une clé détenue par le client.
Comment valider un access token ?
En local avec les clés de /.well-known/jwks.json, ou côté serveur par introspection (RFC 7662) sur /oauth/introspect. La révocation se fait sur /oauth/revoke.
Existe-t-il un SDK ?
Un SDK TypeScript zéro dépendance existe, orienté navigateur. Côté serveur, nous assumons un choix : des standards stricts et un contrat OpenAPI 3.1 public sur /v1/openapi.json, à partir duquel vous générez un client dans votre langage.
Comment fonctionne SCIM ?
Le SCIM 2.0 entrant expose la ressource Users sur /scim/v2/Users ; les groupes se gèrent dans l'annuaire Obexal. Le SCIM sortant provisionne vos applications aval, avec déprovisionnement automatique à la suspension et échecs audités.
Comment donner une identité à un agent IA ?
Chaque agent a ses propres client credentials, avec PAR en option. La délégation au nom d'un utilisateur passe par le Token Exchange (RFC 8693), avec claim act chaîné et downscoping. Plafonds, kill switch et détection d'anomalies : voir Identité des agents IA.
Y a-t-il un environnement de test ?
L'essai gratuit fait office de sandbox : 30 jours, sans carte bancaire, sur accounts.obexal.com. Le statut du service est publié sur /status/ et les évolutions sur /changelog/.
Où est-ce hébergé ?
Obexal est hébergé en France, dans un datacenter en région parisienne, avec résidence des données dans l'UE. Aucune dépendance hors UE dans le chemin des requêtes, aucun CDN externe, polices auto-hébergées. TLS 1.2 minimum, 1.3 privilégié.
Tout le reste est dans la documentation.
Quickstarts, références d'endpoints et guides : tout ce qui précède y est traité en profondeur.