OAuth et Se connecter avec Sporty
Sporty est un fournisseur OAuth 2.1 et OpenID Connect. Votre application peut demander une autorisation à un membre, recevoir un jeton d'accès limité à certains scopes et l'utiliser pour lire ce qu'il a accepté de partager — sans jamais voir son mot de passe, et le membre peut retirer cet accès à tout moment.
Tout ici est standard. N'importe quelle bibliothèque cliente OAuth ou OIDC fonctionnera ; vous ne devriez rien avoir à écrire de spécifique à Sporty.
Quel flux choisir
| Vous développez | Utilisez |
|---|---|
| Une application web, mobile ou de bureau qui agit pour la personne qui l'utilise | Code d'autorisation + PKCE |
| « Se connecter avec Sporty » — vous avez seulement besoin de savoir qui est la personne | Code d'autorisation + PKCE, avec le scope openid |
| Une intégration de serveur à serveur qui agit pour un club, sans personne présente | Identifiants client (client credentials) |
| Un système de réservation qui garde son planning synchronisé avec celui d'un club | Identifiants client, voir Synchroniser les réservations |
| Un agent IA ou un client MCP | Code d'autorisation + PKCE, généralement avec l'enregistrement dynamique |
Il n'y a ni grant par mot de passe ni grant implicite. OAuth 2.1 supprime les deux.
Points de terminaison
Tout se trouve sur https://api.sporty.plus.
| Usage | Point de terminaison |
|---|---|
| Autorisation | GET /oauth2/authorize |
| Jeton | POST /oauth2/token |
| Révocation (RFC 7009) | POST /oauth2/token/revoke |
| Enregistrement dynamique (RFC 7591) | POST /oauth2/register |
| UserInfo | GET /oauth2/userinfo |
| JWKS | GET /oauth2/jwks |
Plutôt que de les coder en dur, récupérez l'un des documents de découverte :
curl https://api.sporty.plus/.well-known/openid-configuration
curl https://api.sporty.plus/.well-known/oauth-authorization-server
curl https://api.sporty.plus/.well-known/oauth-protected-resource
Où les jetons fonctionnent
Un jeton d'accès s'utilise sur l'API partenaire, https://api.sporty.plus/api/partner/v1.
Il ne fonctionnera nulle part ailleurs. En particulier, /api/v3, l'API qu'utilisent nos
propres applications, refuse catégoriquement les jetons OAuth et répond 403 avec un message
qui l'indique. Cette surface est autorisée pour les personnes qui utilisent notre propre
interface, pas pour des applications agissant en leur nom, et y laisser entrer un jeton
accorderait bien plus que ce que décrit n'importe quel écran de consentement.