Passen Sie den HTTP-Header für die Autorisierung an

81

Ich muss einen Client authentifizieren, wenn er eine Anfrage an eine API sendet. Der Client hat ein API-Token und ich habe darüber nachgedacht, den Standard- AuthorizationHeader zu verwenden, um das Token an den Server zu senden.

Normalerweise wird dieser Header für verwendet Basicund DigestAuthentifizierung. Ich weiß jedoch nicht, ob ich den Wert dieses Headers anpassen und ein benutzerdefiniertes Authentifizierungsschema verwenden darf, z.

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

Würden Sie dies empfehlen oder nicht? Oder gibt es einen besseren Ansatz zum Senden des Tokens?

api  http  rest  http-headers  authorization 
— Thomas Watson
quelle

Antworten:

51

Sie können Ihre eigenen benutzerdefinierten Authentifizierungsschemata erstellen, die den Authorization:Header verwenden. So funktioniert OAuth beispielsweise .

Wenn Server oder Proxys die Werte von Standardheadern nicht verstehen , lassen sie diese in der Regel in Ruhe und ignorieren sie. Es werden eigene Header- Schlüssel erstellt , die häufig zu unerwarteten Ergebnissen führen können. Viele Proxys entfernen Header mit Namen, die sie nicht erkennen.

Trotzdem ist es möglicherweise eine bessere Idee, Cookies zum Übertragen des Tokens anstelle des Authorization:Headers zu verwenden, aus dem einfachen Grund, dass Cookies explizit so konzipiert wurden, dass sie benutzerdefinierte Werte enthalten, während die Spezifikation für die integrierten Authentifizierungsmethoden von HTTP nicht wirklich besagt So oder so - wenn Sie genau sehen möchten, was es sagt, schauen Sie hier .

Der andere Punkt dabei ist, dass viele HTTP-Client-Bibliotheken eine integrierte Unterstützung für Digest- und Basic-Authentifizierung haben, aber das Leben möglicherweise schwieriger machen, wenn versucht wird, einen Rohwert im Header-Feld festzulegen, während sie alle eine einfache Unterstützung für Cookies und Willen bieten Erlaube mehr oder weniger irgendeinen Wert in ihnen.

— DaveRandom
quelle
9
Schön zu hören, dass OAuth so funktioniert. Ich bin mir nicht sicher, ob die Verwendung von Cookies die Client-Implementierung vereinfacht. Wenn Ihr Client kein Browser ist, sind die Regeln für die Arbeit mit Cookies (Pfad, Ablauf usw.) in einem Client komplizierter zu implementieren, als nur daran zu denken, ein Header-Feld festzulegen. Die meisten Client-Bibliotheken machen es ziemlich einfach, die richtigen Header festzulegen.
— Thomas Watson
2
@ThomasWatson Obwohl ich Ihnen in Bezug auf die Cookie-Scope-Punkte nicht widersprechen kann, sollte es hier eigentlich keine Rolle spielen. Der Umfang der HTTP-Authentifizierung (unter Verwendung des Authorization:Headers) ist pro Domäne. Dies bedeutet, dass, wenn Sie die Domäne des Cookies auf "diese Domäne" und den Pfad auf "/" setzen, der Bereich mit dem der HTTP-Authentifizierung identisch ist. Es liegt jedoch wirklich an Ihnen - aber wie Julian Reschke betont, sollten Sie wahrscheinlich kein neues Authentifizierungsschema definieren, es sei denn, Sie feel that you have something of generic use- etwas, das in einer anderen Anwendung verwendet werden könnte.
— Dave Random
8

Im Fall einer CROSS ORIGIN- Anfrage lesen Sie Folgendes :

Ich war mit dieser Situation konfrontiert und entschied mich zunächst für die Verwendung des AuthorizationHeaders und entfernte ihn später, nachdem ich mit dem folgenden Problem konfrontiert war.

AuthorizationDer Header wird als benutzerdefinierter Header betrachtet. Wenn also eine domänenübergreifende Anfrage mit dem AutorizationHeader-Satz gestellt wird, sendet der Browser zuerst eine Preflight-Anfrage . Eine Preflight-Anforderung ist eine HTTP-Anforderung der OPTIONS-Methode. Diese Anforderung entfernt alle Parameter aus der Anforderung. Ihr Server muss mit einem Access-Control-Allow-HeadersHeader antworten , der den Wert Ihres benutzerdefinierten Headers ( AuthorizationHeaders) hat.

Für jede Anforderung, die der Client (Browser) sendet, wurde vom Browser eine zusätzliche HTTP-Anforderung (OPTIONS) gesendet. Dies hat die Leistung meiner API verschlechtert. Sie sollten überprüfen, ob das Hinzufügen dies Ihre Leistung beeinträchtigt. Um dieses Problem zu umgehen, sende ich Token in http-Parametern. Ich weiß, dass dies nicht der beste Weg ist, aber ich konnte keine Kompromisse bei der Leistung eingehen.

— Abhishek Kumar
quelle
Ich denke auch darüber nach, nur meine sessionID in http params zu senden. Warum ist das nicht der beste Weg? Es scheint, dass es den Vorteil der Robustheit gegenüber Firewalls hat, die Header entfernen, und auch gegenüber einer Leistungsverschlechterung zwischen verschiedenen Ursprüngen. Was sind ihre Nachteile?
— Donnerstag,
1
Der Nachteil ist nur bei GET-Anfrage. Ich musste den Benutzer mit meinen Authorization token(sensiblen) Daten für meine Anwendung authentifizieren . Aus dem gleichen Grund sollten wir keine vertraulichen Daten in GET senden, wir sollten kein Autorisierungstoken in Parametern verwenden. Gemäß w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 "Das HTTP-Protokoll sollte keine GET-basierten Formulare für die Übermittlung vertraulicher Daten verwenden".
— Abhishek Kumar
Sie können das Token in Cookies speichern, wenn Sie keine Header mögen. (Verwechseln Sie das Token nicht mit der Sitzungs-ID.) Beachten Sie, dass durch PUT und DELETE die OPTIONEN trotzdem gesendet werden. Beachten Sie, dass Sie meistens einen serverseitigen REST-Client verwenden und ein Browser nicht als sehr guter REST-Client angesehen wird.
— inf3rno
5

Dies ist etwas veraltet, aber es gibt möglicherweise andere, die nach Antworten auf dieselbe Frage suchen. Sie sollten sich überlegen, welche Schutzbereiche für Ihre APIs sinnvoll sind. Beispielsweise möchten Sie möglicherweise den Zugriff von Clientanwendungen auf Ihre APIs identifizieren und authentifizieren, um deren Verwendung auf bekannte, registrierte Clientanwendungen zu beschränken. In diesem Fall können Sie die verwendenBasicAuthentifizierungsschema mit der Client-ID als Benutzer-ID und dem gemeinsam genutzten Client-Geheimnis als Kennwort. Sie benötigen keine proprietären Authentifizierungsschemata, sondern identifizieren nur diejenigen, die von Clients für jeden Schutzbereich verwendet werden sollen. Ich bevorzuge nur eines für jeden Schutzbereich, aber die HTTP-Standards erlauben sowohl mehrere Authentifizierungsschemata für jede WWW-Authenticate-Header-Antwort als auch mehrere WWW-Authenticate-Header für jede Antwort. Dies ist für API-Clients verwirrend, welche Optionen verwendet werden sollen. Seien Sie konsistent und klar, dann werden Ihre APIs verwendet.

— Steve Dearborn
quelle
2

Ich würde empfehlen, die HTTP-Authentifizierung nicht mit benutzerdefinierten Schemanamen zu verwenden. Wenn Sie der Meinung sind, dass Sie etwas von allgemeinem Nutzen haben, können Sie jedoch ein neues Schema definieren. Weitere Informationen finden Sie unter http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 .

— Julian Reschke
quelle
Das Dokument, auf das verlinkt werden soll, ist ein Entwurf von HTTP / 1.1. Ich habe versucht, in den endgültigen Standard zu schauen und kann nichts darüber finden. Ich muss benutzerdefinierte Schemata registrieren. Könnte dies nicht nur sein, dass sie während des Entwurfsprozesses die Standardschemata finden und vereinbaren wollten?
— Thomas Watson
Thomas, das Dokument, auf das ich verwiesen habe, ist die Überarbeitung der RFCs 2616/7 (die keine Registrierung für Schemata hatten). Es ist in Arbeit, steht aber kurz vor dem Abschluss.
— Julian Reschke
0

Bitte versuchen Sie es unten mit Postboten: -

Im Header-Abschnitt Beispielarbeit für mich ..

Autorisierung: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU

— Madan Dale
quelle
1
Senden Sie wirklich Passwort / Hash in JWT? Es ist eine einfache base64.
— Zakhar
1
@Zakhar: Es ist eine typische Praxis für SPAs, die gesamte Benutzersitzung in JWT zu kapseln (da es sich um ein vollständiges JSON-Dokument handelt), sodass kein Sitzungsspeicher auf der Serverseite erforderlich ist.
— Cowbert
@cowbert: Ich bin mir nicht sicher, ob es typisch ist, etwas mehr als eine Art Sitzungstoken in JWT zu kapseln (siehe zum Beispiel diesen Beitrag ).
— Alexander Abakumov
@AlexanderAbakumov dieser Artikel voller Irreführungen, er hat einige Punkte bekommen, aber viele seiner Punkte machen keinen Sinn und einige von ihm ist einfach ohne Grund dagegen, ich kann sagen, er liebt Kekse und ich denke, er muss einige davon bekommen Bäckerei und Reparatur seines Artikels, ich habe viele Situationen, in denen ich Cookies verwendet habe und Tage der Arbeit verschwendet habe, JWT mit localStorage hat mir viel Kopfschmerzen und Zeit gespart, es sind nur 2 Stunden Arbeit und Knall, besuchen Sie es nie wieder. Ich frage mich, ob er jemals eine mobile App entwickelt, Browser mit streng eingeschränkten Sicherheitsregeln ausprobiert und so weiter hat.
— Al-Mothafar
@ Al-Mothafar: Ich würde es begrüßen , wenn Sie auf Ihre Aussagen wie erweitern that article full of misleadings, a lot of his points does not make senseusw. in irgendeiner Weise ( das heißt, es ist wahrscheinlich etwas über einen Kommentar hier). Vielleicht könntest du eine Antwort oder einen Blog-Beitrag schreiben? Es wäre wirklich interessant, Argumente zu vergleichen.
— Alexander Abakumov
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.