API-Autorisierung und Authentifikation bei Dienstanbietern
Die Autorisierung entspricht dem Standard OAuth-Modell und ist im folgenden Sequenz-Diagramm dargestellt. Danach werden die beiden Attribut-Listen „Access Token“ basierend auf der Spezifikation OAuth 2.0 Authorization Framework sowie „ID Token“ gemäß der Spezifikation OpenID Connect 1.0 definiert, jeweils mit spezifischen Anpassungen.
Für die Nutzung der in diesem Dokument spezifizierten Schnittstellenendpunkte (REST-APIs) des Schulconnex-Servers ist ein Access Token notwendig. Dieser wird von einem separaten Authentication-Dienst ausgestellt. Den konkreten Endpunkt des Authentication-Dienstes erhalten Sie vom Betreiber des Schulconnex-Servers.
Für die Autorisierung eines Dienstes und die Authentifikation einer nutzenden Person gegenüber
der REST-API wird das OAuth 2.0 Protokoll verwendet. Gemäß der Spezifikation IETF RFC 6749
„The OAuth 2.0 Authorization Framework” muss der REST-API-Endpunkt für den „OAuth 2.0 Token Exchange“
(siehe IETF RFC 8693 ”OAuth 2.0 Token Exchange”) genutzt werden. Über die Schnittstelle wird
einer Client-Anwendung im Erfolgsfall ein JSON mit Token ausgestellt; dieser beinhaltet unter
anderem die Autorisierung eines Dienstes (den OAuth access_token).
Die Attribute für den erfolgreichen OAuth 2.0 Token Exchange sind im Unterkapitel
„Access Token“ definiert. Bei dem access_token
handelt es sich um eine Zugriffsberechtigung in Form einer Zeichenkette, welche von den
Client-Anwendungen bei den darauffolgenden HTTP-Anfragen gegen die REST-API im Authorization
Header verwendet wird (siehe Attribut token_type); dies ist in IETF RFC 6750
„The OAuth 2.0 Authorization Framework: Bearer Token Usage“ spezifiziert.
Das ID Token führt unter anderem das Attribut sub (kurz für subject identifier). Der Wert des
Attributs sub entspricht einer für die Client-Anwendung pseudonymisierten ID pid der angemeldeten
nutzenden Person im gewählten Sicherheitskontext. Das Datenmodell für den id_token ist im
Unterkapitel „ID Token“ beschrieben.
Dieser ID Token wird bei der Autorisierung eines Dienstes im Sicherheitskontext einer angemeldeten
Nutzerperson (OAuth 2.0 Authorization Code Grant) ausgestellt und als Attribut id_token im JSON
der erfolgreichen OAuth 2.0 Token Exchange Anfrage geführt. Der für die Client-Anwendung pseudonymisierte
Identifier (Id) der nutzenden Person beschreibt die Person im Sicherheitskontext der Anmeldung und ist
als Attribut sub im id_token enthalten.
In einigen Fällen ist es für Dienstanbieter wünschenswert, neben der PID bereits bei der Autorisierung weitere Informationen über die angemeldete Person zu erhalten. Dieses kann, nach Absprache mit dem Betreiber des Schulconnex-Servers, durch die Nutzung von OIDC Claims geschehen. Die Nutzung von OIDC Claims zur Übermittlung von Schulconnex-Informationen ist in Kapitel „Person-Info über OIDC Claims“ beschrieben. Im Regelfall sollten aber die REST-APIs zur Abfrage von Informationen genutzt werden.
Für darauffolgende Anfragen der Client-Anwendungen gegen einen API-Endpunkt des Schulconnex-Services
muss der access_token als Authorization Header im XMLHttpRequest (XHR) verwendet werden.
Das Attribut token_type beim OAuth 2.0 Token Exchange Request referenziert die Art der Verwendung
des access_token – gemäß IETF RFC 6750 „The OAuth 2.0 Authorization Framework: Bearer Token Usage“ oder
den Basic und Digest Authentifizierungsschemata.
Im Kontext der Spezifikation OpenID Connect muss das Attribut token_type den Wert "Bearer" führen.
Access Token
Die folgende Tabelle beschreibt die Attribute für die JSON-Antwort einer OAuth
2.0-Token-Exchange-Anfrage. Diese JSON-Struktur beinhaltet unter anderem die Autorisierung
eines Dienstangebots (den OAuth access_token) und die Authentifikation einer nutzenden Person
(den OpenID Connect id_token). Beim Berechtigungstyp „OAuth 2.0 Client Credentials Grant