Verwendung von Inhaber-Token

Ich habe mich in den letzten Jahren mit dem Bereich der digitalen Identität beschäftigt. Ein großer Teil dieser Arbeit besteht darin, Spezifikationen zu lesen (und manchmal zu erstellen), wie Sie sich vorstellen können. Es ist wichtig, dass sie so geschrieben sind, dass zwei unabhängige Parteien interoperable Implementierungen erstellen können, ohne sich auf den Code der anderen verlassen zu müssen. Lassen Sie uns vor diesem Hintergrund ein kurzes Gespräch über die Verwendung von OAuth2-Bearer-Token führen, wobei der Schwerpunkt auf der Codierung des Tokens liegt.

Aber lassen Sie uns zuerst kurz darüber sprechen, was OAuth2 ist .

Was ist OAuth 2.0?

OAuth2 ist ein von RFC6749 definiertes Autorisierungsframework , das den Gesamtfluss von Nachrichten zwischen drei Akteuren beschreibt: einem "Client", einem Ressourcenbesitzer (Resource Owner, RO) und einem Autorisierungsserver (AS). Möglicherweise kennen Sie die ersten beiden jeweils als "vertrauende Seite" und "user". Diejenigen unter Ihnen, die mit OpenID Connect vertraut sind, kennen den AS auch als "Identity Provider".

Im Kern geht es bei OAuth2 darum, dass ein Benutzer eine vertrauende Seite für den Zugriff auf seine Daten autorisiert, die von einer durch den Autorisierungsserver geschützten API gehostet werden. Beachten Sie, dass der Benutzer selbst nicht zum Zugriff auf die API berechtigt ist. Die Aufgabe des AS besteht darin, die Zustimmung des Benutzers zur Autorisierung des Zugriffs der vertrauenden Seite einzuholen und aufzuzeichnen.

Vielleicht haben Sie die Betonung des Frameworks oben bemerkt. Das liegt daran, dass RFC6749 bewusst auf normative Texte verzichtet, die viele Umsetzungsdetails definieren. Wenn RFC6749 ein wenig zurückgeht, sagt lediglich, dass es einen Client gibt, der Zugriff auf eine Ressource anfordert, die durch einen Autorisierungsserver geschützt ist, und dass der Ressourcenbesitzer diesen Zugriff genehmigen muss. Nach der Autorisierung erhält der Client ein Zugriffstoken, um die Ressource.

OAuth2 stützt sich auf das HTTP-Protokoll und definiert die Grundstruktur der Nachrichten, die zwischen seinen Akteuren fließen. Relevant für das vorliegende Thema ist das, was in der Antwort an den Kunden enthalten ist. Gemäß dem RFC stellt dieses Attribut "dem Client die Informationen zur Verfügung, die erforderlich sind, um das Zugriffstoken erfolgreich zu verwenden, um eine Anforderung an eine geschützte Ressource zu stellen".

OAuth 2.0 Bearer Token Usage

RFC6750 ist die normative Spezifikation für die Verwendung von OAuth 2.0 Bearer-Token.

Was sind "Bearer Tokens"?

Rufen Sie das Attribut von oben auf. Es stellt sich heraus, dass, wenn die Zugriffstokenantwort angibt, dass der Typ des Tokens ist, es sich um ein "Bearertoken" handelt, wie es in RFC6750 definiert ist, was bedeutet:

Dies ist bei weitem die häufigste Art von Zugriffstoken, die heute im Web verwendet wird.

Großartig! Ich möchte Social Logins in meine Über-Mega-Website integrieren und einen Markt aufmischen übernacht! Fangen wir an!

Die Irreleitung

Sie haben einen der OAuth 2-Grant-Typen (auch bekannt als "Flows") als Client implementiert und der AS hat eine access_token an Sie ausgegeben. Was nun? Wie verwenden wir dieses Token?

Zu unserem Glück sagt uns RFC6750 genau, was zu tun ist! Oder doch? Schauen wir uns meinen Gedankengang bei meinem ersten Versuch einer Implementierung an:

• Der Client muss einen HTTP-Header mit dem Token auf eine bestimmte Weise formatieren.
• Die Syntax von Bearer-Token enthält ein : 'b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" Dies
• deutet stark darauf hin, dass die Base64-Codierung in irgendeiner Weise beteiligt ist
• . Aber wer codiert die access_token in Base64?
• Denken Sie daran, dass die access_token für den Client normalerweise undurchsichtig ist.
• Beachten Sie, dass HTTP-Header fast jedes US-ASCII-Zeichen haben können.
• Denken Sie daran, dass das access_token so ziemlich aus allen druckbaren Zeichen besteht - eine Obermenge von Base64
• Wenn das access_token für den Client undurchsichtig ist (ich sollte nicht versuchen, es zu analysieren) und es kann auch aus ungültigen Base64-Zeichen bestehen, dann muss der Client das Token sicherlich Base64-codieren, oder?

Aber sind wir sicher? Lassen Sie uns RFC6750 noch einmal überprüfen:

• Die Syntax des Header-Feldes "Authorization" für dieses Schema folgt der Verwendung des in Abschnitt 2 von RFC2617 definierten Basisschemas.
• Im Folgenden stellen wir fest, dass RFC2617 das HTTP-Authentifizierungsschema definiert, das auch den HTTP-Header und Base64 verwendet, um die Anmeldeinformationen zu codieren

Alles zusammenfügt:

• RFC6750 definiert, wie OAuth 2.0-Bearer-Token verwendet
• werden. Der access_token muss in den Header eingefügt
• werden. Die Syntax umfasst: ein Zeichenraum
,
• der durch Diese Verwendung folgt dem Schema in RFC2617
• RFC2617 verwendet Base64-Codierung

Großartig! Alles, was ich tun muss, ist, die access_token in Base64 zu codieren, bevor ich sie in den Header einfüge. Ich bin bereit, meine Social Logins zu integrieren!

Erzähler: Er war noch nicht bereit für die Integration.

Die

Realitäts-Bearer-Token werden im Header offengelegt.

Keine der vorhandenen Implementierungen erwartet, dass die access_token in Base64 im Header codiert wird. Siehe zum Beispiel:

Was gibt es? Haben sich alle anderen geirrt? (denn natürlich habe ich die Spezifikation richtig interpretiert!)

Gewonnene Erkenntnisse

Es ist wichtig, dass die Spezifikationen einen genauen normativen Text darüber enthalten, wie die Botschaften konstruiert und verarbeitet werden, um interoperabel zu sein. Wenn Algorithmen beteiligt sind, geben Sie diese Schritt für Schritt an .

Es ist wichtig, dass normative Texte als solche gekennzeichnet werden.

Es ist wichtig, jede Rolle und ihre jeweiligen Verantwortlichkeiten und Algorithmen zu identifizieren.

Meiner Meinung nach ist die Webauthentifizierung ein gutes Beispiel, das die vorherigen Punkte verdeutlicht:

Ich kämpfe immer noch mit einer echten Konsolidierung von RFC6750 und Realität. Wenn ich genau richtig blinzele, kann ich sehen, dass, wenn RFC6750 sagt "Die Syntax für Bearer-Anmeldeinformationen lautet wie folgt", der Client-Entwickler unnötigerweise darüber informiert wurde, wie die Syntax des Tokens lautet. Im Nachhinein scheint dies eine (eher knappe) Nachricht zu sein, die für Implementierer von Autorisierungsservern gedacht ist. Ich denke, eine verbesserte Version dieses Abschnitts wäre aufgeteilt worden in Mehrere Teile, die sich jeweils an unterschiedliche Zielgruppen richten: einer für Entwickler von Clients, ein anderer für Entwickler von Autorisierungsservern und ein weiterer für Entwickler von Ressourcenservern. Der Text in RFC6750 bleibt jedoch knapp und vermischt mehrere Umsetzungsdetails, die die verschiedenen Akteure auf unterschiedliche Weise betreffen.

Eine weitere Verbesserung bestünde darin, sich weniger auf Beispiele zu verlassen und normative Beschreibungen der (sehr einfachen) Verarbeitungsalgorithmen bereitzustellen, die diese Nachrichten konstruieren und analysieren. Dies hätte den größten Teil der Verwirrung in Abschnitt 2.1 ausgeräumt, obwohl die Formulierung selbst eine stärkere Formulierung hätte vertragen können. In der Tat hat der nicht-normative Text in Abschnitt 7.1 von RFC6749 eine stärkere Formulierung als der in RFC6750!

Wie auch immer, als Implementierer gilt: Überprüfen Sie immer Ihr Verständnis einer Spezifikation im Vergleich zu anderen Implementierungen!

oauth2authn