Die API verwendet OAuth 2.0 mit PKCE zur Authentifizierung.
WarnungDie Basic-Authentifizierung ist veraltet und wird in einem zukünftigen Update entfernt. Bitte stelle auf OAuth 2.0 um.
client_id zu erhaltenDie meisten OAuth-2.0-Client-Bibliotheken wickeln diesen Ablauf automatisch ab, wenn du ihnen den Server-Metadaten-Endpunkt /.well-known/oauth-authorization-server angibst.
Alle folgenden Endpunkte sind relativ zu https://api.attendium.com.
Erstelle in Attendium eine OAuth-Anwendung, um deine client_id zu erhalten, und bei einer vertraulichen Anwendung auch dein client_secret. Das musst du nur einmal pro Anwendung tun. Siehe OAuth-Anwendungen.
Redirect-URIs müssen https verwenden oder für die lokale Entwicklung http mit einer Loopback-Adresse (localhost, 127.0.0.1 oder ::1). Eine öffentliche Anwendung kann auch ein Private-Use-URI-Schema in umgekehrter Domain-Notation verwenden, etwa com.example.app:/oauth/callback.
Mit dem Erstellen einer OAuth-Anwendung – ob in Attendium oder über die dynamische Client-Registrierung – akzeptierst du die Entwicklerbedingungen in der zu diesem Zeitpunkt veröffentlichten Fassung.
Erzeuge einen PKCE-Code-Verifier und eine Code-Challenge:
A-Z, a-z, 0-9, -, ., _, ~) – das ist dein code_verifiercode_challengeLeite den Benutzer dann weiter zu:
GET /oauth2/authorize?response_type=code
&client_id=your-client-id
&redirect_uri=https://yourapp.example.com/callback
&code_challenge=your-code-challenge
&code_challenge_method=S256
&state=random-state-value
Der Benutzer meldet sich bei Attendium an und wird mit einem Authorization-Code (code) und deinem state-Wert zu deiner redirect_uri zurückgeleitet.
POST /oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=your-client-id
&redirect_uri=https://yourapp.example.com/callback
&code=the-authorization-code
&code_verifier=your-code-verifier
Eine vertrauliche Anwendung muss sich zusätzlich selbst authentifizieren, entweder per Basic-Authentifizierung (client_secret_basic) oder indem sie das client_secret im Body der Anfrage sendet (client_secret_post):
POST /oauth2/token
Authorization: Basic base64(your-client-id:your-client-secret)
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&redirect_uri=https://yourapp.example.com/callback
&code=the-authorization-code
&code_verifier=your-code-verifier
Die Antwort enthält ein access_token und ein refresh_token.
Gib das Zugriffstoken im Authorization-Header mit:
curl -H "Authorization: Bearer your-access-token" \
-H "Content-Type: application/json" \
-d '{"query": "{ me { id } }"}' \
https://api.attendium.com/graphql
Die Token-Antwort enthält ein Feld expires_in, das angibt, wie lange das Zugriffstoken gültig ist. Verwende das Refresh-Token, um ein neues Zugriffstoken zu erhalten, bevor das aktuelle abläuft:
POST /oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=your-client-id
&refresh_token=your-refresh-token
Eine vertrauliche Anwendung authentifiziert diese Anfrage auf dieselbe Weise wie beim Eintauschen des Authorization-Codes.
Anwendungen, die sich anhand der Server-Metadaten selbst konfigurieren – darunter KI-Assistenten, die sich über MCP verbinden (siehe MCP einrichten) –, registrieren sich selbst, indem sie eine POST-Anfrage an /oauth2/register senden. Das brauchst du nicht, wenn du deine OAuth-Anwendung in Attendium erstellst.
POST /oauth2/register
Content-Type: application/json
{
"redirect_uris": ["https://yourapp.example.com/callback"],
"client_name": "Meine Anwendung"
}
Eine auf diese Weise registrierte Anwendung wird nicht unter „OAuth-Anwendungen“ aufgeführt, daher können ihr Name, ihre Redirect-URIs und ihr Client-Secret dort nicht geändert werden.