Weitere Informationen
OAuth 2.0 ist als RFC 6749 standardisiert. Ein ausführliches Dokument finden Sie unter https://oauth.net/2. Die Basisauthentifizierung in HTTP wird in Abschnitt 2 von RFC 2617 definiert.
Übersicht
Normalerweise muss der Endnutzer (Ressourceninhaber) seine Anmeldedaten an den Drittanbieter weitergeben, um Anwendungen von Drittanbietern Zugriff auf eingeschränkte Ressourcen wie Datentarif und Wallet-Details zu gewähren. Dadurch entstehen verschiedene Probleme und Einschränkungen wie die Speicherung von Anmeldedaten, die Passwortauthentifizierung, der weitreichende Zugriff auf die Ressourcen des Endnutzers und die Weitergabe von Passwörtern usw. Durch OAuth 2.0 werden diese Probleme behoben, indem eine Autorisierungsebene eingeführt und so der Zugriff auf die geschützten Ressourcen des Endnutzers sichergestellt und eingeschränkt wird.
Anstatt die Anmeldedaten des Endnutzers für den Zugriff auf geschützte Ressourcen wie Details des Datentarifs zu verwenden, erhält die GTAF ein Zugriffstoken. Die Zugriffstokens werden dem GTAF im Namen der Anmeldedaten des GTAF ausgestellt. Die GTAF verwendet dann das Zugriffstoken, um auf die vom DPA gehosteten Datentarifdetails zuzugreifen.
Die folgende Abbildung bietet einen allgemeinen Informationsfluss:
Abbildung 1. Abstrakter OAuth-Ablauf.
Zugriffstokens
Zugriffstokens sind die Anmeldedaten, die vom GTAF verwendet werden, um vom DPA des Mobilfunkanbieters auf Details zum Datentarif zuzugreifen. Ein Zugriffstoken ist ein String, der eine für die GTAF ausgestellte Autorisierung darstellt. Der String ist in der Regel nicht transparent für den GTAF. Tokens stellen bestimmte Bereiche und die Dauer des Zugriffs dar, die dem Endnutzer vom Mobilfunkanbieter gewährt und vom DPA und OAuth-Server des Mobilfunkanbieters erzwungen werden.
Das Zugriffstoken stellt eine Abstraktionsebene zur Verfügung und ersetzt verschiedene Autorisierungskonstrukte (z.B. Nutzername und Passwort) durch ein einzelnes Token, das von der DPA verstanden wird. Durch diese Abstraktion können Zugriffstokens restriktiver als die zum Erhalt der Autorisierung verwendete Berechtigung ausgestellt werden. Außerdem müssen die DPAs eine Vielzahl von Authentifizierungsmethoden verstehen.
Zugriffstokens können je nach Sicherheitsanforderungen des Mobilfunkanbieters verschiedene Formate, Strukturen und Nutzungsmethoden haben (z.B. kryptografische Properties). GTAF unterstützt nur Zugriffstokens mit Inhabertyp, die in [RFC6750] definiert sind.
Clientauthentifizierung
Der GTAF dient als „vertraulicher Client“ und kann Passwörter schützen. Die GTAF unterstützt derzeit nur die HTTP-Basisauthentifizierung, um sich beim DPA zu authentifizieren. Die Client-ID wird mit dem Codierungsalgorithmus &application-x-www-form-urlencoded" codiert und der codierte Wert wird als Nutzername verwendet. Das Passwort wird mit demselben Algorithmus codiert und als Passwort verwendet.
Vertrauliche Clients wie GTAF, die Clientanmeldedaten erhalten, authentifizieren sich beim OAuth-Server des Mobilfunkanbieters, während sie Anfragen an das Token-Endpunkt senden. Die Clientauthentifizierung wird verwendet für: \
- Wiederherstellung aus einem manipulierten Client, indem der Client deaktiviert oder seine Anmeldedaten geändert werden, um zu verhindern, dass ein Angreifer gestohlene Aktualisierungstokens missbraucht Das Ändern eines einzelnen Satzes von Clientanmeldedaten ist wesentlich schneller als das vollständige Entfernen aller Aktualisierungstokens.
- Best Practices für die Authentifizierungsverwaltung implementieren, die eine regelmäßige Rotation von Anmeldedaten erfordern.
Die GTAF verwendet den Parameter "client_id" zur Identifizierung beim Senden von Anfragen an den Token-Endpunkt.
Von besonderer Bedeutung ist die Möglichkeit, Clientanmeldedaten zu rotieren. Der OAuth-Server muss zwei Arten gleichzeitiger Anmeldedaten während der Rotation unterstützen und Anmeldedaten deaktivieren können. Bei einer typischen Rotation von Anmeldedaten gilt:
- Der Mobilfunkanbieter erstellt neue Anmeldedaten auf dem OAuth-Server und sendet diese auf sichere Weise an seinen technischen Account Manager.
- Google testet die neuen Anmeldedaten und ändert die GTAF-Konfiguration so, dass die neuen Anmeldedaten verwendet werden.
- Google informiert den Mobilfunkanbieter, dass die alten Anmeldedaten deaktiviert werden können.
- Der Mobilfunkanbieter deaktiviert die Anmeldedaten und benachrichtigt Google
- Google prüft, ob die alten Anmeldedaten nicht mehr funktionieren
Der OAuth-Server muss den obigen Rotationsprozess unterstützen.
Token-Endpunkt
Der Token-Endpunkt wird vom GTAF verwendet, um ein Zugriffstoken zu erhalten, indem das Autorisierungs- oder Aktualisierungstoken präsentiert wird. Der Token-Endpunkt wird bei jeder Autorisierungsgewährung mit Ausnahme des impliziten Berechtigungstyps verwendet, da ein Zugriffstoken direkt ausgestellt wird.
Hier sind einige Punkte, die beim Konfigurieren eines Tokenendpunkts zu berücksichtigen sind:
- Der Standort des Token-Endpunkts sollte in der Dienstdokumentation angegeben sein.
- Der Endpunkt-URI kann eine formatierte Abfragekomponente „&appt;application/x-www-form-urlencoded“ enthalten, die beim Hinzufügen zusätzlicher Abfrageparameter beibehalten werden muss. Der Endpunkt-URI darf keine Fragmentkomponente enthalten.
- Da Anfragen an den Token-Endpunkt zur Übertragung von Klartext-Anmeldedaten führen (in der HTTP-Anfrage und -Antwort), muss der OAuth-Server des Mobilfunkanbieters TLS verwenden, um Anfragen an den Token-Endpunkt zu senden.
- Die GTAF verwendet die HTTP-Methode &POST, wenn eine Anforderung für ein Zugriffstoken erfolgt.
- Parameter, die ohne Wert gesendet werden, müssen so behandelt werden, als wären sie in der Anfrage weggelassen. Der OAuth-Server muss nicht erkannte Anfrageparameter ignorieren. Anfrage- und Antwortparameter dürfen nur einmal enthalten sein.
- GTAF unterstützt nur Zugriffstokens mit Inhabertyp.
Zugriffstokenbereich
Über die Autorisierungs- und Tokenendpunkte kann der Client den Bereich der Zugriffsanfrage mit dem Anfrageparameter "scope" angeben. Der Autorisierungsserver wiederum verwendet den Antwortparameter "scope", um den Client über den Umfang des ausgestellten Zugriffstokens zu informieren.
Der Wert des Bereichsparameters wird als eine Liste von durch Leerzeichen voneinander getrennten Strings angegeben, bei denen die Groß- und Kleinschreibung berücksichtigt wird. Die Strings werden vom Autorisierungsserver definiert. Wenn der Wert mehrere durch Leerzeichen getrennte Strings enthält, ist die Reihenfolge nicht relevant. Jeder String fügt dem angeforderten Bereich einen zusätzlichen Zugriffsbereich hinzu.
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
Für GTAF muss der Bereich nicht implementiert werden, diese Funktion wird aber unterstützt. Weitere Informationen findest du in Abschnitt 3.3 von RFC 6749.
Zugriffstoken ausstellen
Wenn die vom GTAF gesendete Zugriffstokenanfrage gültig und autorisiert ist, gibt der OAuth-Server ein Zugriffstoken und ein optionales Aktualisierungstoken aus. Wenn die Anfrage die Clientauthentifizierung fehlschlägt oder ungültig ist, gibt der OAuth-Server eine Fehlerantwort zurück, wie im folgenden Abschnitt beschrieben.
Erfolgreiche Antwort
Wenn die GTAF-Anfrage eine Anfrage sendet, stellt der OAuth-Server ein Zugriffstoken und ein optionales Aktualisierungstoken aus und konstruiert die Antwort. Dazu werden die folgenden Parameter dem Entitätstext der HTTP-Antwort mit dem Statuscode 200 (OK) hinzugefügt: \
- access_token:ERFORDERLICH. Das vom OAuth-Server ausgestellte Zugriffstoken. GTAF erwartet, dass der Token-Endpunkt ein Inhabertoken zurückgibt.
- expires_in:REQUIRED Die Lebensdauer des Zugriffstokens in Sekunden. Der Wert „3600“ gibt beispielsweise an, dass das Zugriffstoken in einer Stunde ab dem Zeitpunkt der Antwort abläuft. Wenn keine Angabe gemacht wird, sollte der OAuth-Server die Ablaufzeit auf andere Weise angeben oder den Standardwert dokumentieren.
- token_type: ERFORDERLICH. Der Typ des ausgestellten Tokens. Weitere Informationen zu verschiedenen Arten von Tokens finden Sie in Abschnitt 7.1 in RFC 6749. Beim Wert wird nicht zwischen Groß- und Kleinschreibung unterschieden. GTAF unterstützt nur Inhabertokens zum Zeitpunkt der Veröffentlichung dieser Informationen.
- refresh_token:OPTIONAL. Das Aktualisierungstoken, mit dem neue Zugriffstokens mit derselben Autorisierungserteilung abgerufen werden können.
- scope (optional): wenn implementiert und mit dem vom GTAF angeforderten Bereich identisch; andernfalls erforderlich
Die Parameter werden im Text der Entität in der HTTP-Antwort mithilfe von "application/json" eingeschlossen. Die Parameter werden in eine JSON-Struktur (JavaScript Object Notation) serialisiert, indem jeder Parameter auf der höchsten Strukturebene hinzugefügt wird. Parameternamen und Stringwerte sind als JSON-Strings enthalten. Numerische Werte sind als JSON-Nummern enthalten. Die Reihenfolge der Parameter ist unerheblich und kann variieren.
Der Autorisierungsserver MUSS das HTTP-Antwortheaderfeld „Cache-Control“ mit dem Wert „no-store“ in jeder Antwort mit Tokens, Anmeldedaten oder anderen vertraulichen Informationen enthalten und das Antwortfeld „Pragma“ mit dem Wert „no-cache"“ enthalten.
Beispiele:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
Beachten Sie dabei Folgendes:
- Die GTAF ignoriert unbekannte Wertenamen in der Antwort.
- Die Größe der vom OAuth-Server empfangenen Tokens und anderen Werte bleibt nicht definiert.
- Der GTAF sollte keine Annahmen zu Wertgrößen treffen. Der OAuth-Server sollte die Größe jedes von ihm ausgegebenen Werts dokumentieren.
Fehlerantwort
Wenn eine Autorisierungsanfrage aus irgendeinem Grund fehlschlägt, z. B. aufgrund eines fehlenden, ungültigen oder nicht übereinstimmenden Weiterleitungs-URI, oder wenn die Clientkennung fehlt oder ungültig ist, sollte der OAuth-Server mit dem Statuscode „HTTP 400 (Bad Request)“ antworten (sofern nicht anders angegeben) und mindestens einen der im Abschnitt „Fehlerantwort und Codes“ aufgeführten Parameter enthalten.
Autorisierungserteilung in GTAF
Autorisierungsautorisierungen sind Anmeldedaten, die für die Autorisierung des Endnutzers (für den Zugriff auf geschützte Ressourcen, z. B. für Daten zur Datennutzung) verwendet werden. Diese Berechtigungen werden von der GTAF verwendet, um ein Zugriffstoken abzurufen.
Die GTAF verwendet den Berechtigungstyp client_credentials. Im Berechtigungstyp client_credentials fordert GTAF ein Token mithilfe einer HTTP-POST-Anfrage und der HTTP-Basisauthentifizierung an. Alle Anfragen werden über TLS gesendet (d.h. HTTPS) und GTAF können ohne gültiges TLS-Zertifikat nicht in einen OAuth-Server integriert werden. GTAF kann einen konfigurierbaren Tokenbereich übergeben und gibt einen leeren Bereich weiter, wenn keiner konfiguriert ist.
GTAF erwartet, dass ein Zugriffstoken mit dem Wert &exptes_in" (Gültigkeitsdauer) zurückgegeben wird. Der Wert „expiration_in“ sollte mindestens 900 Sekunden und nicht mehr als ein paar Stunden betragen. Die Anforderung eines neuen Tokens darf nicht dazu führen, dass vorhandene Tokens frühzeitig ablaufen.
Weitere Informationen zu den verschiedenen Berechtigungstypen finden Sie in Abschnitt 1.3 von RFC 6749.
Beispielanfrage und -antwort
Angenommen, der GTAF hat für einen OAuth-Server die folgende Konfiguration:
URL: https://www.example.com/gettoken/
Client ID: gtaf
Client secret: password
Scope: dpa
Hinweis:Der Clientschlüssel für einen tatsächlichen Datenschutzbeauftragten muss viel sicherer als der hier gezeigte sein.
Zum Erstellen des Autorisierungsstrings sind die Client-ID ':' und das Passwort verkettet und base64-codiert. Dies kann folgendermaßen in einer Befehlszeile repliziert werden:
$ echo -n gtaf:password | base64
Z3RhZjpwYXNzd29yZA==
GTAF sendet dann mit diesen Anmeldedaten, dem Gewährungstyp "client_credentials" und dem konfigurierten Bereich eine HTTPS-POST-Anfrage an den OAuth-Server. Die GTAF-Anfrage sieht in etwa so aus:
$ curl -H 'Authorization: Basic Z3RhZjpwYXNzd29yZA==' -X POST \
-d 'grant_type=client_credentials&scope=dpa' 'https://www.example.com/gettoken/'
Die von GTAF verwendeten Header stimmen nicht mit denen überein, die von curl gesendet werden. Der Autorisierungsheader ist jedoch identisch.
GTAF erwartet eine Antwort im folgenden Format:
{
"access_token":"<token>",
"token_type": "Bearer",
"expires_in":<expiration time>
}
Hier ein Beispiel für eine gültige Antwort:
{
"access_token":"YXRudWhhZXVoLGFodWFoaGF1aG9zaHVvYWV1Cg",
"token_type": "Bearer",
"expires_in":3600
}
Hinweis:Die Antwort muss eine gültige JSON-Datei sein.
Fehlerantwort und Codes
Wenn eine Autorisierungsanfrage von GTAF aus einem der im Abschnitt „Fehlerantwort“ angegebenen Gründe fehlschlägt, muss der OAuth-Server den HTTP-Statuscode 400 (Fehlerhafte Anfrage) zurückgeben (sofern nicht anders angegeben) und einen der folgenden Parameter mit der Antwort enthalten:
Beispiel: \
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}
GTAF erwartet, dass der OAuth-Server die folgenden Fehlerantworten unterstützt:
| Fehlercode | Antwort | Grund |
| HTTP 400 | ungültige Anfrage | In der Anfrage fehlt ein erforderlicher Parameter, enthält einen nicht unterstützten Parameterwert (außer dem Berechtigungstyp), wiederholt einen Parameter, enthält mehrere Anmeldedaten, verwendet mehr als einen Mechanismus zur Authentifizierung beim GTAF oder ist anderweitig fehlerhaft. |
| HTTP 401 | Ungültiger_Client | Clientauthentifizierung fehlgeschlagen (z.B. unbekannter Client, keine Clientauthentifizierung oder nicht unterstützte Authentifizierungsmethode). Der OAuth-Server kann den HTTP-Statuscode 401 (Nicht autorisiert) zurückgeben, um anzugeben, welche HTTP-Authentifizierungsschemas unterstützt werden. Wenn der Client versucht hat, sich über das Anfrageheader-Feld „Autorisierung“ zu authentifizieren, muss der OAuth-Server den HTTP-Statuscode 401 (Nicht autorisiert) zurückgeben und das Antwortheader-Feld „WWW-Authentifizieren“ mit dem vom Client verwendeten Authentifizierungsschema einfügen. |
| HTTP 500 | Fehler bei OAuth-Server |
Details zu anderen Antworten, die für die Fehlerbehebung verwendet werden können, findest du in Abschnitt 5.2 von RFC 6749.