Ich schreibe derzeit Code zum Umgang mit oAuth (mit der Azure Graph-API, aber ich glaube, die Google-APIs sind ähnlich).
Um einen API-Aufruf zu tätigen, benötige ich ein Zugriffstoken, das eine Gültigkeitsdauer von etwa einer Stunde hat. Um das Zugriffstoken zu erhalten, muss ich zuerst den Benutzer dazu bringen, die Nutzung meiner App zu autorisieren. Dadurch wird ein Autorisierungscode mit einer Gültigkeitsdauer von etwa zehn Minuten erstellt. Gleichzeitig mit dem Zugriffstoken kann ich auch ein Aktualisierungstoken erhalten, das normalerweise eine Gültigkeitsdauer von 90 Tagen hat. Allerdings kann ich vor Ablauf ein neues Aktualisierungstoken erhalten, um sicherzustellen, dass ich ein gültiges Aktualisierungstoken behalte.
Es müssen also drei Arten von Codes/Tokens bearbeitet werden.
Warum werden all diese verschiedenen Codes und Token benötigt? Warum stellt man nicht einfach einen Autorisierungscode mit einer Gültigkeit von 90 Tagen bereit und fertig?
Gehe ich recht in der Annahme, dass ich, wenn mein Aktualisierungstoken abläuft, ganz zum Anfang der Kette zurückkehren und bei meinem Benutzer erneut Zugriff anfordern muss?
Antwort1
Warum werden all diese verschiedenen Codes und Token benötigt? Warum stellt man nicht einfach einen Autorisierungscode mit einer Gültigkeit von 90 Tagen bereit und fertig?
Der Autorisierungscode ist eine von mehreren Möglichkeiten, das Zugriffstoken bereitzustellen – es handelt sich dabei nicht um einen separaten „Schritt“, sondern ist immer noch Teil des anfänglichen „interaktiven Authentifizierungs“-Ablaufs. Er unterscheidet sich vom eigentlichen Zugriffstoken dadurch, dass Sie auch das OAuth2-Clientgeheimnis (oder die zu Beginn generierte PKCE-Challenge) benötigen, um den Code verwenden zu können. Theoretisch bedeutet dies, dass selbst wenn der Code selbst abgefangen wird (z. B. durch auf der Clientseite sichtbare Umleitungen), nur die ursprüngliche App ihn gegen das echte Token austauschen kann.
Es gibt andere Abläufe, bei denen kein solches Zertifikat verwendet wird. Sie können beispielsweise den Ablauf „Implicit Grant“ verwenden, um das Zugriffstoken direkt zu erhalten, oder Sie können ein Zertifikat verwenden, um das Token in einem Schritt zu authentifizieren und zu erhalten, je nachdem, was der OAuth-IDP unterstützt.
(Beispielsweise authentifizieren sich „Dienstkonten“ bei Google mithilfe eines RSA-Schlüsselpaars, um ein Zugriffstoken zu erhalten. Sie verwenden nicht den interaktiven Authentifizierungsablauf und daher gibt es keinen Authentifizierungscode.)
Gehe ich recht in der Annahme, dass ich, wenn mein Aktualisierungstoken abläuft, ganz zum Anfang der Kette zurückkehren und bei meinem Benutzer erneut Zugriff anfordern muss?
Ja, aber genau das zu vermeiden, ist ja der eigentliche Zweck eines Refresh-Tokens.
Wenn Sie nur einen Tokentyp (einen Zugriffstoken) hätten, müssten Sie jedes Mal, wenn dieser abläuft, wieder ganz an den Anfang der Kette zurückkehren. Dies wird normalerweise durch einen Aktualisierungstoken vermieden, der normalerweise einenviel längerLebensdauer, d. h. wenn der Zugriffstoken mehrere Stunden oder Tage gültig ist, ist es üblich, dass der Aktualisierungstoken Monate oder Jahre gültig ist.
Ich würde sagen, dass 90 Tage für ein Aktualisierungstoken ungewöhnlich kurz sind und den Sinn eines solchen irgendwie zunichte machen – ich vermute, dass Azure OAuth2 speziell so eingerichtet ist, um eine erneute Authentifizierung durch schwerer zu stehlende Anmeldeinformationen zu erzwingen, wie z. B. ein Gerätezertifikat oder das benutzerdefinierte HMAC-Schema, das „Windows Hello“ verwendet. (Im Gegensatz dazu scheinen von Google ausgegebene Aktualisierungstoken praktisch keine Ablaufzeit zu haben – ich verwende dasselbe Token seit Jahren, um auf Gmail IMAP zuzugreifen.)
Antwort2
Es gibt verschiedene Typen, weil sie unterschiedlichen Zwecken dienen. Ein einfacher Grund, warum Sie sie haben, ist, dass sie kompromittiert und für unterschiedliche Zwecke verwendet werden könnten. Wenn sie also nur eine kurze Lebensdauer haben, ist sichergestellt, dass eine unsachgemäße Handhabung oder ein kompromittierter Client zwar immer noch schädlich, aber potenziell weniger Auswirkungen haben könnte.
Es hilft auch, zu trennen, was was tut. Ein Token würde bedeuten, dass Sie nur einen Token in die Hände bekommen müssten und alles tun könnten. Wenn Sie mehrere Token haben, ist es etwas schwieriger, die Option zu bekommen, alles zu tun.
Sehendas RFC 6749für weitere Informationen zu den Token-Typen.