Frage:
Warum OpenID Connect anstelle von einfachem OAuth2 verwenden?
rdmueller
2013-06-21 11:18:15 UTC
view on stackexchange narkive permalink

Ich habe gerade angefangen, OAuth 2.0 zu verwenden, um meine Benutzer zu authentifizieren. Es funktioniert großartig - ich verwende nur die Identitäts- / Profil-API jedes Anbieters, um eine validierte E-Mail-Adresse des Benutzers zu erhalten.

Jetzt lese ich über OpenID Connect und bin ein bisschen verwirrt.

Was ist der Unterschied zwischen OpenID Connect und der Verwendung der Identitäts-API über OAuth2? Ist es nur so, dass ich eine Standard-Profil-API habe, damit ich mir keine Sorgen machen muss, ob ich eine "E-Mail" oder eine "E-Mail" JSON zurück bekomme?

Oder steckt mehr dahinter, wodurch der OpenID Connect-Ansatz sicherer ist als mein erster Ansatz?

Okay, ich wusste nichts über "OpenID Connect", ich verstand es als "OpenID" + "Connect". Ich bin sicher, dass Sie dies bereits überprüft haben: http://softwareforallseasons.blogspot.fr/2011/10/oauth-vs-openid-connect.html + Ich schlage vor, Sie bearbeiten Ihre Frage so, dass sie OAuth 2.0 statt nur liest OAuth.
@Aki: Ja, ich habe den Blog-Beitrag gesehen, konnte aber nichts daraus machen.
@Ralf: Aus meiner Sicht können Sie Apps mit oauth erstellen und die Freigabe bestimmter Ressourcen, die mit dem Benutzerkonto verknüpft sind, autorisieren oder nicht. Mit openid connect wird es einfacher, der Anbieter muss keine eigene Schicht über oauth implementieren, um damit umzugehen, und Clients haben eine Standardmethode für den Zugriff auf Daten.
"Ich verwende nur die Identitäts- / Profil-API jedes Anbieters **, um eine validierte E-Mail-Adresse ** des Benutzers zu erhalten." Dies bedeutet, dass Sie die Anzahl der zulässigen Anbieter einschränken müssen. Ein beliebiger Anbieter garantiert keine Validierung. Alternativ können Sie E-Mail-Adressen ablehnen, die nicht mit der Domain des Anbieters übereinstimmen.
In einem Artikel auf [oauth.net heißt es: OAuth 2.0 ist kein Authentifizierungsprotokoll] (http://oauth.net/articles/authentication/).Es ist eigentlich ein Autorisierungsrahmen.Sie empfehlen die Verwendung von OpenID Connect (das auf OAuth 2.0 basiert), wenn Sie eine Authentifizierung wünschen.
Ich fand diese YouTube-Videopräsentation sehr hilfreich: [* OAuth 2.0 und OpenID Connect (im Klartext) *] (https://youtu.be/996OiexHze0) von Nate Barbettini.
Sechs antworten:
flup
2013-12-17 09:33:57 UTC
view on stackexchange narkive permalink

OpenID Connect gibt Ihnen ein Zugriffstoken sowie ein ID-Token. Das ID-Token ist ein JWT und enthält Informationen zum authentifizierten Benutzer. Es ist vom Identitätsanbieter signiert und kann ohne Zugriff auf den Identitätsanbieter gelesen und überprüft werden.

Darüber hinaus standardisiert OpenID Connect einige Dinge, die oauth2 der Wahl überlässt. Zum Beispiel Bereiche, Endpunkterkennung und dynamische Registrierung von Clients.

Dies erleichtert das Schreiben von Code, mit dem der Benutzer zwischen mehreren Identitätsanbietern wählen kann.

Sind Sie sicher, dass Ihre Aussage "OpenID Connect gibt Ihnen ein Zugriffstoken plus ein ID-Token."ist richtig?Ich dachte, eine Anwendung kann ein id_token haben und es mit einer anderen Anwendung teilen und dann ein Zugriffstoken von dieser Anwendung erhalten.OIDC fährt über dem OAuth2-Protokoll, aber Sie erhalten nicht unbedingt beide.Obwohl es die meiste Zeit passieren kann.
"OpenID Connect gibt Ihnen ein Zugriffstoken sowie ein ID-Token.">> In den meisten Fällen ist dies korrekt und wie es normalerweise gehandhabt wird.Sie stellen * eine * Anfrage, die aus "token id_token" als Antworttypen und "openid" als Gültigkeitsbereich besteht und gleichzeitig ein Zugriffstoken und ein ID-Token zurückgibt.Das ID-Token ist für den Client bestimmt, während das Zugriffstoken für den Client undurchsichtig sein soll und in Schutzanforderungen an den Ressourcenserver weitergeleitet werden soll, z. B. eine API oder ein anderes Backend.
"Ich dachte, eine Anwendung kann ein id_token haben und es mit einer anderen Anwendung teilen und dann ein Zugriffstoken von dieser Anwendung erhalten.">> Sie tauschen kein ID-Token gegen ein Zugriffstoken aus, wenn Sie dies gemeint haben.Und beides sind Probleme des Autorisierungsservers / IdP, nicht von einer anderen Anwendung oder einem anderen Ressourcenserver (obwohl Autorisierungsserver und Ressourcenserver manchmal identisch sein können).
Nereis
2014-01-21 20:07:21 UTC
view on stackexchange narkive permalink

OAuth bietet nur und sollte nur eine Autorisierung mithilfe eines Zugriffstokens bereitstellen. OpenID Connect basiert auf OAuth 2, um Informationen zur Benutzerauthentifizierung bereitzustellen. Es bietet Ihnen jedoch keine robustere Implementierung als OAuth (da es OAuth verwendet und einige zusätzliche Interaktionen mit einem OpenID-Anbieter hinzufügt).

OpenID Connect 1.0 ist eine einfache Identitätsschicht darüber das OAuth 2.0 [RFC6749] -Protokoll. Es ermöglicht Clients, die Identität des Endbenutzers anhand der von einem Autorisierungsserver durchgeführten Authentifizierung zu überprüfen und grundlegende Profilinformationen über den Endbenutzer auf interoperable und REST-ähnliche Weise abzurufen. OpenID Connect Core 1.0 - Entwurf 17

OpenID Connect bietet Ihnen eine "Standard" -Methode zum Abrufen der Benutzeridentität. Wenn Sie OAuth und die API verwenden, sollten Sie Ihre Anforderung für jede Ressource anpassen, die möglicherweise nicht immer dieselben Informationen enthält oder sich im Laufe der Zeit ändert. Und konzeptionell verwenden Sie OAuth, um eine API verwenden zu dürfen, nicht um einen Benutzer zu authentifizieren.

Als Hintergrund werden das OAuth 2.0 Authorization Framework [RFC6749] und die OAuth 2.0 Bearer Token Usage [RFC6750] verwendet. Spezifikationen bieten einen allgemeinen Rahmen für Anwendungen von Drittanbietern, um eingeschränkten Zugriff auf HTTP-Ressourcen zu erhalten und zu verwenden. Sie definieren Mechanismen zum Abrufen und Verwenden von Zugriffstoken für den Zugriff auf Ressourcen, definieren jedoch keine Standardmethoden zum Bereitstellen von Identitätsinformationen. Insbesondere kann OAuth 2.0 ohne Profilerstellung keine Informationen zur Authentifizierung eines Endbenutzers bereitstellen. OpenID Connect Core 1.0 - Entwurf 17

Beachten Sie, dass OpenID connect ein id_token mit einigen Informationen zum Benutzer bereitstellt. Wenn Sie jedoch alle Informationen benötigen, benötigen Sie immer noch das access_token , um den OpenID-Anbieter aufzufordern, die Benutzerinformationen abzurufen (was mich beim ersten Mal verwirrt hat). Dies zeigt, dass das Anfordern von Benutzerinformationen von einer API oder vom OpenID-Anbieter fast dieselbe Methode verwendet. Siehe 5.3.1. Benutzerinfo-Anfrage im Entwurf.

Diese Antwort ist absolut richtig.Ich wollte nur auf eine Kleinigkeit hinweisen: "Wenn Sie jedoch alle Informationen benötigen, benötigen Sie immer noch das access_token, um den OpenID-Anbieter aufzufordern, die Benutzerinformationen abzurufen." >> Dies ist je nach Autorisierungsserver nicht unbedingt der Fall/ kaputt verwendet: Es ist auch möglich, das vollständige Profil bereits in das ID-Token = JWT-Token oder sogar andere Informationen mit benutzerdefinierten Ansprüchen aufzunehmen.Ein Beispiel ist https://auth0.com/docs/tokens/id-token#add-custom-claims.Dann müssen Sie die Anforderung / userinfo nicht mehr ausführen.
Tim
2015-02-26 10:12:29 UTC
view on stackexchange narkive permalink

OAuth ist ein Autorisierungsprotokoll, mit dem die Berechtigung zum Zugriff auf eine geschützte Ressource erteilt werden kann. Ein Nebenprodukt des Autorisierungsprozesses ist die Authentifizierung des Benutzers.

Technisch gesehen muss OAuth Ihnen keine Informationen über den Benutzer geben. Es wird überprüft, ob der Benutzer der Anwendung die Berechtigung zum Zugriff auf einige Daten erteilt hat. Dies wird durch den Umfang der Autorisierungsgewährung geregelt.

OpenID Connect bietet der Anwendung eine Möglichkeit, Informationen über den authentifizierten Benutzer abzurufen. Vor allem bietet es ein gewisses Maß an Sicherheit, dass die Informationen gültig sind (soweit es den Autorisierungsserver betrifft). Dies kann dann verwendet werden, um den Identitätsverbund zu erleichtern.

In der Vergangenheit wurde der Verbund mit OAuth erreicht, indem ein Bereich gewährt wurde, der den Zugriff auf die Identitätsinformationen des Benutzers ermöglichte. OpenID Connect standardisiert diesen Bereich.

Der externe Anbieter muss noch opend Id unterstützen, oder?Sie können Open ID nicht einfach als Client für diese externen Dienste zusätzlich zu vorhandenen Oauth 2-Anbietern implementieren.
Mike Schwartz
2016-06-24 00:02:41 UTC
view on stackexchange narkive permalink

OpenID Connect ist ein Profil von OAuth2 ..., das eine Architektur definiert, mit der eine Person einen Identitätsanbieter autorisieren kann, bestimmte Benutzeransprüche an einen Client (Website / mobile Anwendung) freizugeben.

OAuth2 bietet die Erteilung der Berechtigungsnachweise für Ressourceninhaber, die von IAM-Experten zu Recht als "The Devil" bezeichnet werden.

Ein gängiges Muster für die OpenID Connect-API besteht aus drei Schritten:
1) Abrufen eines Codes
2) Abrufen von Token wie access_token , refresh_token und id_token
3) Abrufen von Benutzerinformationen, die Ansprüche wie Benutzername, E-Mail usw. enthalten br> Das Schema für das id_token, bei dem es sich um ein JWT handelt, wird wie viele andere Details im OpenID Connect-Bereich definiert.

Ein weiterer Grund für die Verwendung von OpenID Connect ist, dass es eine sichere Lösung für die zentralisierte Authentifizierung für mobile Software gibt (mindestens IOS und Android). Die derzeit von Google definierte Best Practice besteht darin, neue Sicherheitsfunktionen zu verwenden, die verhindern, dass eine mobile Anwendung Cookies oder Anmeldeinformationen in einer Webansicht sieht. Google hat die AppAuth IOS- und Android-Bibliotheken veröffentlicht, weil sie wirklich nicht möchten, dass Sie Google-Anmeldeinformationen verlieren! Zum Zeitpunkt dieses Schreibens gibt es mehrere OpenID-Anbieter (auch bekannt als IDPs ...), die die Google OpenID Connect AppAuth-Software unterstützen, darunter: Google, OKTA, Ping und mein Produkt Gluu.

Siehe Außerdem:

  • OAuth 2.0 für native Apps Entwurf-wdenniss-oauth-native-Apps-02
  • AppAuth für IOS
  • AppAuth für Android
    • Alex White
    2015-12-24 17:32:39 UTC
    view on stackexchange narkive permalink

    Die Verwendung von OAuth als Authentifizierungsmethode wird nicht empfohlen, sondern wird explizit als delegierte Autorisierungsmethode konzipiert.

    Facebook verwendete OAuth als Authentifizierungsmethode, aber eine unternehmungslustige Person entdeckte, wie der access_token von Facebook - vollständiger Blogeintrag

    OpenID Connect macht es viel schwieriger, Zugriffstoken über einen solchen Mechanismus zu stehlen.

    danke für den link - muss überprüfen was den unterschied macht ...
    OK. Lesen Sie den Blogeintrag. Für mich liest sich das so, als hätte Facebook einige Sicherheitslücken implementiert, aber nicht, dass OAuth kaputt ist ... Wenn ich also das OAuth-Schema verwende, bei dem ich den Zugriffstoken Server-zu-Server überprüfen muss, kann das im Blog beschriebene Problem nicht auftreten Ich bin immer noch davon überzeugt, dass OAuth - richtig implementiert - ziemlich gut ist ...
    In diesem Fall wird besser erklärt, warum die Verwendung von OAuth als Authentifizierungsmechanismus zu Sicherheitslücken führt: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
    Utsav
    2013-10-11 18:52:08 UTC
    view on stackexchange narkive permalink

    Open ID Connect basiert auf OAuth und ist daher robuster. OAuth ist das Protokoll, das nur für die Autorisierung verwendet wird, und Open ID Connect ist OAuth sehr ähnlich, kombiniert jedoch auch die Funktion von OAuth. Mit diesem Protokoll können Sie die Kommunikation zwischen Ihren RPs und IPs starten. Das OAuth-Protokoll weist verschiedene Lücken auf. Verwenden Sie daher besser Open Id Connect.

    Es wäre interessant zu wissen, warum diese Antwort abgelehnt wurde ...
    Auf welche Lücken beziehen Sie sich (ehrliche Neugier)? Ich kämpfe mit der gleichen Frage wie das OP. Es scheint, dass oAuth2 (auf dem Openid Connect basiert) bereits eine Authentifizierung durchführt, obwohl ich mit den Session-Hijacking- und MiM-Wiederholungsangriffen vertraut bin, die mit einfachen Bearer-Token möglich sind. Sind dies die Lücken, auf die Sie sich beziehen?
    7 Jahre später ... werden diese Lücken von OIDC sicherlich nicht gelöst?Sie haben immer noch Zugriffstoken und sie tun immer noch dasselbe, was sie in OAuth2 in OIDC tun sollten?Mir scheint, wenn Sie Fehler in Ihrer Implementierung von OAuth2 haben, wird die Überlagerung von OIDC diese Probleme nicht lösen.


    ⓘ
    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...