Wir haben eine Anwendung in ASP.NET MVC geschrieben, die aus Web (nicht Ruhe, mit Rasiermesser) und API-Projekten (und einigen anderen Projekten, aber das ist neben dem Punkt jetzt) besteht.
Die Authentifizierung im Web erfolgt mit Hilfe von Standardformularen und die Authentifizierung in der API erfolgt über OAuth2.
Es hat sich als etwas schwierig herausgestellt, zwei Authentifizierungsmethoden in derselben Anwendung zu pflegen. Daher haben wir uns entschieden, die Formularauthentifizierung zu verwerfen und OAuth2 für Web- und API-Projekte zu verwenden.
Im Webprojekt müssten wir wahrscheinlich OAuth2-Tokens in Cookies speichern, anstatt sie als Header zu senden. Ist es möglich, OAuth2 zum Sichern von "Nicht-Ruhe" -Anwendungen zu verwenden? Wenn ja, gibt es Sicherheitsbedenken?
Es gibt einige ausgezeichnete Artikel zu den Themen, die Sie interessieren. Diese Artikel erklären die Details, die Sie suchen.
Diese Seiten werden der Ausgangspunkt sein. OAuth 2.0 wird oft kritisiert, aber die Sicherheitslücken, auf die alle hinweisen, sind auch in anderen Authentifizierungsmodellen üblich. Wenn diese Sicherheitslücken in der Anwendung behoben werden, mindern sich die Sicherheitsprobleme.
Aber es muss auch angemerkt werden, dass OAuth2 nicht die nächste Generation von OAuth1 ist. Hier finden Sie einen ausgezeichneten Artikel hier .
Die klare Antwort wäre, ja, es ist möglich und gut, sich auf OAuth 2.0 zu verlassen, aber die ehrlichste Antwort wäre, es hängt irgendwie davon ab und es gibt mehr als eine Möglichkeit, das zu tun.
Wenn Ihre Webanwendung vollständig unabhängig ist und nicht als Client der API fungiert, würde ich persönlich einen OAuth 2.0 / OpenID Connect-Flow verwenden, um den Benutzer authentifizieren zu lassen, ein Token zu erhalten, das seine Identität beweist und dann erstellt eine reguläre Sitzung basierend auf Cookies. Wenn ich reguläre Sitzung sage, meine ich eine Sitzung, die serverseitig gespeichert ist und der Cookie enthält nur eine eindeutige Kennung für diese Sitzung.
Sie können auch das tatsächliche Token im Cookie speichern und staatenlos gehen, aber ich sehe den Vorteil nicht. In den meisten Fällen möchte eine Webanwendung genügend Informationen in einer Sitzung speichern, um die Idee, alles in einem Cookie zu speichern, einfach nur schlecht zu machen. Ja, Sie können das Zugriffstoken speichern und haben dann immer noch den Sitzungsstatus auf der Serverseite, die diesem Token zugeordnet ist. Was würden Sie jedoch beim Speichern des tatsächlichen Tokens erreichen?
In diesem Fall können die Dinge anders ausgehen. Ausgehend von Ihrer Frage basiert Ihre Webanwendung auf ASP.NET MVC, daher nehme ich an, dass die API-Aufrufe auf der Serverseite stattfinden.
Ich würde immer noch mit der Erstellung einer regulären Sitzungskennung in einem Cookie nach der Authentifizierung beginnen, anstatt das eigentliche Token zu speichern, aber wichtiger als das müssen Sie entscheiden, was zu tun ist, wenn das Token abläuft Sie können die Anwendungssitzung so lange ausführen, wie es das Token erlaubt, und dann den Benutzer zwingen, den gesamten Authentifizierungsprozess zu wiederholen, um ein neues Token zu erhalten, aber nur wenn Ihre Zugriffstoken eine wirklich lange Lebensdauer haben (was normalerweise verpönt ist, nicht üblich) und auch nicht empfohlen) das ist wirklich schlecht für die Benutzererfahrung.
Meine Neigung, einen Sitzungsbezeichner anstelle des Tokens selbst zu verwenden, liegt nur daran, dass es bei Träger-Tokens, wenn es keine funktionale Anforderung ist, den Token für den Client verfügbar zu haben, nicht so ist, wie Sie es sonst sind nur die Auswirkungen im Falle einer Verletzung zu erhöhen.
Persönlich würde ich in diesem Szenario auf die Optimierung des OAuth-Tokens zurückgreifen, um die Webanwendung weiterhin aktualisieren zu können Zugriffstoken, während die Benutzersitzung aktiv ist. Auf diese Weise können Sie einfach eine gleitende Sitzung implementieren, die so lange aktiv ist, wie der Benutzer ist, und gleichzeitig Zugriffstoken mit kürzeren Lebenszeiten verwenden, die die Auswirkungen eines ausgelaufenen Zugriffstokens verringern.
Hier finden Sie einige Ressourcen für weiterführende Informationen zu Cookies / Sitzungen und Token-Authentifizierung, die Ihnen dabei helfen können, einige verschiedene Perspektiven zur Unterstützung des Entscheidungsprozesses zu erhalten:
Tags und Links asp.net-mvc asp.net oauth authentication rest