Warum ist ' Inhaber ' vor dem Token in ' Autorisierung Header in einer HTTP-Anfrage?

Was genau ist der Unterschied zwischen den folgenden zwei Headern:

Authorization : Bearer cn389ncoiwuencr vs Authorization : cn389ncoiwuencr 

Alle Quellen Was ich durchlaufen habe, setzt den Wert des Headers „Authorization“ auf „Bearer“, gefolgt vom eigentlichen Token. Ich konnte jedoch die Bedeutung nicht verstehen. Was ist, wenn ich das Token einfach in den Authorization-Header stecke?

Kommentare

  • Es gibt andere Methoden der http-Authentifizierung, wie basic oder Digest . Ich nehme an, es ist ' schön, sie unterscheiden zu können.
  • Die Frage bezieht sich speziell auf die Token-basierte Authentifizierung, die normalerweise nach der Basisauthentifizierung für den Benutzer erfolgt ' muss nicht bei jeder Anfrage den Benutzernamen und das Passwort angeben.
  • Ich hatte auch eine ähnliche Frage. Ich wollte ein Schema für eine kurzlebige Token-Implementierung auswählen, das nicht vollständig Oauth 2.0-kompatibel ist. Ich habe mich gefragt, ob ich Bearer oder einen nicht standardmäßigen Wert verwenden kann, ohne Probleme mit der Interpretation von Proxys ' und Servern ' zu bekommen. Am ehesten fand ich eine Antwort: stackoverflow.com/questions/7802116/… und stackoverflow.com/questions/8463809/…
  • Geben Server im Allgemeinen ein Token über dieselbe Route zurück dh " Autorisierung: Träger " der HTTP-Antwort? Oder ist es fast immer Teil des Antwortkörpers?
  • Diese HTTP-Authentifizierungsseite auf MDN ist für die Diskussion sehr nützlich.

Antwort

Das Muster Authorization: <type> <credentials> wurde vom W3C in HTTP 1.0 und wurde seitdem an vielen Stellen wiederverwendet. Viele Webserver unterstützen mehrere Autorisierungsmethoden. In diesen Fällen reicht es nicht aus, nur das Token zu senden.

Websites, die das Format

Authorization : Bearer cn389ncoiwuencr 

verwenden, implementieren höchstwahrscheinlich OAuth 2.0 Inhaber-Token . Das OAuth 2.0-Autorisierungsframework legt eine Reihe anderer Anforderungen fest, um die Autorisierung sicher zu halten. Dies erfordert beispielsweise die Verwendung von HTTPS / TLS.

Wenn Sie sich in einen Dienst integrieren, der OAuth 2.0 verwendet, sollten Sie sich mit dem Framework vertraut machen, damit der von Ihnen verwendete Ablauf gleich ist Richtig implementiert und Vermeidung unnötiger Sicherheitslücken. Es gibt eine Reihe guter Online-Tutorials.

Kommentare

  • I ' Ich bin mit der MS Graph-API nicht vertraut, könnte eine Eigenart ihrer Implementierung sein.
  • Das habe ich mir gedacht. Angesichts Ihrer Kenntnisse über Inhaber-Token und Token im Allgemeinen können Sie jede Sicherheit erkennen Implikationen durch die Tatsache, dass die API das Token wi akzeptiert Ohne das Schlüsselwort Bearer?
  • Nicht wirklich, aber ich stimme einem Kommentar in dieser Frage zu – wenn sich ihre Implementierung in diesem Punkt unterscheidet, was ist dann noch anders? Davon abgesehen gibt es eine Reihe von OAuth-ähnlichen Implementierungen, die von den RFCs abweichen. Dies bedeutet jedoch nicht automatisch, dass ihre Implementierungen weniger sicher sind.

Antwort

Lange vor der Autorisierung des Inhabers, Dieser Header wurde für Basisauthentifizierung verwendet. Für die Interoperabilität unterliegt die Verwendung dieser Header den W3C-Normen. Selbst wenn Sie den Header lesen und schreiben, sollten Sie diese befolgen. Der Inhaber unterscheidet die Art der Autorisierung, die Sie verwenden, daher ist dies wichtig.

Antwort

Im Autorisierungsheader jeder HTTP-Anforderung für Inline-Aktionen wird ein Inhaber-Token festgelegt, und der Träger selbst bestimmt die Art der Authentifizierung.

Ref https://developers.google.com/gmail/markup/actions/verifying-bearer-tokens

Kommentare

  • Diese Antwort ist spezifisch für Google Mail-Entwickler, nicht für alle Webentwickler. Eine ' -Aktion ' ist a Google Mail-Konzept.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.