Was ist OAuth?

Das Erstellen neuer Konten für verschiedene Websites war schon immer mühsam. Die meisten davon sind überflüssige Arbeit, da sie alle dieselben Benutzerinformationen enthalten, wie Name und Telefonnummer.

„Ist es möglich, einer App den Zugriff auf meine Daten zu erlauben, ohne ihr mein Passwort zu geben?“

OAuth ist ein Standard, der versucht, dieses Problem zu lösen, indem er eine zentralisierte Autorisierung bereitstellt.

OAuth, was für „Open Authorization“ steht, ist ein offener Standard für die Zugriffsdelegierung. Es ermöglicht Ihnen (Ressourcenbesitzern), Informationen zwischen Anwendungen und Websites zu teilen, ohne Ihre Passwörter preiszugeben. Es wird weit verbreitet verwendet, und Sie nutzen wahrscheinlich täglich OAuth-Dienste. Zum Beispiel können Sie sich bei GeeksforGeek mit Ihrem Google-Konto anmelden. Dadurch autorisieren Sie GeeksforGeek, auf einige der Informationen in Ihrem Google-Konto zuzugreifen, wie Benutzername, Profilbild usw.

Geschichte von OAuth

Das OAuth 1.0-Protokoll wurde im April 2010 als RFC 5849, ein informatives Request for Comments, veröffentlicht.

Das OAuth 2.0-Protokoll wurde im Oktober 2012 als RFC 6749 veröffentlicht, und die Verwendung von OAuth 2.0 Bearer Token wurde als RFC 6750 veröffentlicht.

Obwohl es auf den Erfahrungen mit OAuth 1.0 aufbaut, ist OAuth 2.0 eine komplette Neugestaltung von OAuth 1.0, die nur die allgemeinen Ziele und das Benutzererlebnis teilt. OAuth 2.0 ist nicht abwärtskompatibel mit OAuth 1.0.

Wie OAuth 2.0 funktioniert

Im OAuth-Protokoll verwendet der Client anstelle des Benutzernamens und Passworts des Ressourcenbesitzers ein Access Token, um auf geschützte Ressourcen zuzugreifen. Der Client erhält das Access Token von einem Autorisierungsserver, nachdem der Ressourcenbesitzer seine Zustimmung erteilt hat. Damit der Ressourcenbesitzer den Client autorisieren kann, muss er sich zuerst bei der Anwendung authentifizieren. Da die Authentifizierung nur zwischen dem Ressourcenbesitzer und der Anwendung stattfindet, kann der Drittanbieter-Client keine privaten Informationen des Ressourcenbesitzers erfahren.

Wir können sehen, dass die Implementierung des OAuth-Protokolls den Authentifizierungsprozess für Drittanbieter-Clients erheblich vereinfacht. Alles, was er tun muss, ist die Autorisierung des Benutzers einzuholen, das Access Token anzufordern, es zu verwenden und die Benutzerinformationen (geschützte Ressource) zu erhalten. Es ist nicht erforderlich, dass neue Benutzer Konten registrieren oder ihre Anmeldedaten preisgeben, wodurch die Angriffsfläche verringert und die Netzwerksicherheit erhöht wird.

Es ist erwähnenswert, dass OAuth keine Authentifizierung ist. Das „Auth“ hier steht für Autorisierung. Der Benutzer meldet sich nicht bei der Anwendung an. Er autorisiert lediglich die Drittanbieter-Anwendung, einige seiner Informationen zu erhalten.

OAuth-Autorisierungsprozess

Rollen

OAuth definiert vier Rollen:

Client - Die Anwendung, die auf Ihre (Ressourcenbesitzer) Daten zugreifen und geschützte Ressourcenanfragen im Namen des Ressourcenbesitzers und mit dessen Autorisierung stellen möchte.

Ressourcenbesitzer - Ein Benutzer, der die Daten im Ressourcenserver besitzt, den Dienst des Clients nutzen möchte und ein Konto auf dem Autorisierungsserver hat. Zum Beispiel bin ich der Ressourcenbesitzer meines Facebook-Profils und möchte den Dienst von GeeksforGeeks nutzen.

Autorisierungsserver - Die Hauptkomponente von OAuth. Gibt Access Tokens an den Client aus, nachdem der Ressourcenbesitzer erfolgreich authentifiziert und die Autorisierung erteilt wurde.

Ressourcenserver - Der Server, der die Daten speichert, auf die der Client zugreifen möchte, und in der Lage ist, geschützte Ressourcenanfragen mit Access Tokens zu akzeptieren und zu beantworten.

OAuth-Protokollablauf

Schritt A: Die Drittanbieter-Anwendung fordert die Autorisierung des Benutzers an

Schritt B: Die Drittanbieter-Anwendung erhält eine Autorisierungsgenehmigung, die eine Berechtigung darstellt, die die Autorisierung des Ressourcenbesitzers repräsentiert

Schritt C: Die Drittanbieter-Anwendung fordert ein Access Token unter Verwendung der Autorisierungsgenehmigung an

Schritt D: Der Autorisierungsserver authentifiziert den Client und validiert die Autorisierungsgenehmigung. Wenn sie gültig ist, gibt er ein Access Token an die Drittanbieter-Anwendung aus

Schritt E: Die Drittanbieter-Anwendung verwendet das Access Token, um die geschützten Ressourcen vom Ressourcenserver anzufordern

Schritt F: Der Ressourcenserver validiert das Access Token und bearbeitet die Anfrage, wenn es gültig ist

Autorisierungscode und Access Token

Es gibt vier Arten von Autorisierungsgenehmigungen, um Access Tokens von Autorisierungsservern zu erhalten. Wir werden hier nur über die Autorisierungscode-Methode sprechen, da sie die sicherste und gebräuchlichste Methode ist.

Schritt A: Die Drittanbieter-Anwendung lässt den Benutzer eine Autorisierungsmethode auswählen, z.B. GitHub, und leitet den Benutzer dann mit Parametern wie client_id und redirect_uri an den Autorisierungsserver weiter

Anfragebeispiel:

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

Schritt B: Der Benutzer meldet sich an und autorisiert

Schritt C: Der Autorisierungsserver leitet den Benutzer gemäß der redirect_uri zurück zum Backend der Drittanbieter-Anwendung und stellt den Autorisierungscode bereit

Antwortbeispiel:

     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

Schritt D: Die Drittanbieter-Anwendung verwendet den Autorisierungscode, um das Access Token vom Autorisierungsserver einzutauschen

Anfragebeispiel:

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Schritt E: Der Autorisierungsserver validiert und gibt das Access Token zurück

Beispielantwort vom Autorisierungsserver:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

Ein konkretes Beispiel

Bob möchte seine Amazon-Bestellungen mit einer Software namens Rabbit schön formatieren.

Ressourcenbesitzer -> Bob

Client (Drittanbieter-Anwendung) -> Software Rabbit

Autorisierungsserver -> Amazons Autorisierungsserver

Ressourcenserver -> Amazons Datenbanken zur Speicherung von Bestellinformationen

Geschützte Ressourcen -> Bobs Bestellinformationen auf Amazon

Warum sollten Autorisierungscode und Access Token separat bezogen werden?

Der Autorisierungscode und das Access Token werden separat bezogen, um Sicherheitsmaßnahmen zu gewährleisten.

Im OAuth2-Protokoll ist der Autorisierungscode ein temporärer Code, den der Client gegen ein Access Token eintauscht. Der Code wird vom Autorisierungsserver bezogen, wo der Benutzer (Ressourcenbesitzer) die Möglichkeit hat, zu sehen, welche Informationen der Client anfordert, und die Anfrage zu genehmigen oder abzulehnen.

Sobald der Benutzer sich erfolgreich anmeldet und autorisiert, wird er mit einem temporären Autorisierungscode in der URL zurück zur Anwendung geleitet.

Dieser Autorisierungscode ist in der Regel zehn Minuten lang gültig und kann nur einmal verwendet werden. Die kurze Gültigkeitsdauer verringert das Risiko, dass Benutzerinformationen gestohlen werden. Im Gegensatz dazu ist die Gültigkeitsdauer des access_token relativ lang, normalerweise 1 bis 2 Stunden. Wenn es gestohlen wird, kann es eine größere Gefahr für die Datensicherheit der Benutzer darstellen.

Darüber hinaus muss der Client, um ein Access Token einzutauschen, zusätzlich zum Autorisierungscode client ID und client secret bereitstellen. Der Autorisierungsserver benötigt diese Parameter, um den Client zu authentifizieren und zu überprüfen, ob derjenige, der das Access Token anfordert, vertrauenswürdig ist. Wenn der Autorisierungscode versehentlich gestohlen wird, der Hacker aber nicht über die client ID und das client secret verfügt, kann er das Access Token dennoch nicht erhalten. Selbst wenn er irgendwie über die client ID und das client secret verfügt, muss er immer noch mit dem Client-Server konkurrieren, da der Autorisierungscode nur einmal verwendet werden kann. Dieser Mechanismus erhöht die Schwierigkeit potenzieller Angriffe erheblich. Wenn wir den Schritt des Bezugs des Autorisierungscodes überspringen und das Access Token direkt zurückgeben, könnte der Angreifer das Access Token leicht verwenden, um Benutzerinformationen zu stehlen.

OIDC (OpenID Connect)

Was ist der Zweck der Verwendung von OAuth für die Autorisierung? Es geht darum, alle möglichen Informationen über den Benutzer zu erhalten. Warum können wir die Ausgabe nicht standardisieren, damit Drittanbieter-Anwendungen sie direkt verwenden können?

OIDC macht diese Standardisierung.

Wie macht OIDC das? Einfach ausgedrückt, gibt es zusätzlich zum access token ein id_token im JWT-Format zurück, das die grundlegenden Benutzerinformationen enthält. Drittanbieter-Anwendungen können die Benutzerinformationen erhalten, indem sie den Signaturalgorithmus überprüfen und die Signatur auf dem id_token mit einem öffentlichen Schlüssel verifizieren.

Darüber hinaus bietet OIDC den UserInfo-Endpunkt. Drittanbieter-Dienste können das Access Token verwenden, um auf diesen Endpunkt zuzugreifen und zusätzliche Informationen über den Benutzer zu erhalten.

Ein weiteres Merkmal von OIDC ist Single Sign On (SSO) und Single Log Out (SLO). SSO verbessert die Benutzerfreundlichkeit, indem es dem Benutzer ermöglicht, authentifizierte Sitzungen mit verschiedenen Clients zu haben, ohne jedes Mal Anmeldeinformationen eingeben zu müssen. Solange der Benutzer sich erfolgreich bei einer Anwendung anmeldet, muss er das Passwort nicht erneut eingeben, wenn er sich bei anderen Anwendungen anmeldet.

SLO verbessert die Sicherheit, indem sichergestellt wird, dass nach dem Single Logout des Benutzers keine aktiven Sitzungen mehr von einer SSO-Sitzung übrig bleiben. Benutzer müssen sich nur einmal abmelden und alle Sitzungen werden beendet, wodurch verhindert wird, dass sie gehijackt oder missbraucht werden.

Es ist erwähnenswert, dass OIDC keine spezifische Authentifizierungsmethode standardisiert, wie Passwörter oder Gesichtserkennung. Stattdessen spezifiziert es, wie die Authentifizierung an einen zentralisierten Authentifizierungsanbieter delegiert wird, was wir nach der Authentifizierung erhalten - id token, wie dieses Token verifiziert wird - JWT-Format, und welche Benutzerinformationen dieses id token enthält. Drittanbieter-Anwendungen müssen also nicht mehr das Rad neu erfinden.

APISIX’s Unterstützung für OAuth/OIDC

Apache APISIX ist ein Open-Source-Cloud-native API-Gateway. Es ist ein dynamisches, Echtzeit-, Hochleistungs-API-Gateway, das Sie verwenden können, um traditionellen Nord-Süd-Verkehr sowie Ost-West-Verkehr zwischen Diensten zu handhaben. Es kann auch als k8s Ingress-Controller verwendet werden.

Da APISIX ein API-Gateway ist, das als Proxy für mehrere Upstream-Anwendungsserver fungiert, ist es am natürlichsten, die zentralisierte Autorisierung und Authentifizierung auf dem API-Gateway zu platzieren.

Das OpenID Connect (OIDC)-Plugin von APISIX unterstützt das OpenID Connect-Protokoll. Benutzer können dieses Plugin verwenden, um APISIX mit vielen Identitätsanbietern (IdP) zu verbinden, wie z.B. Okta, Keycloak, Ory Hydra, Authing usw., und es als zentralisiertes Authentifizierungsgateway bereitzustellen. OIDC ist eine Obermenge von OAuth, daher unterstützt dieses Plugin auch OAuth.

Bereitstellungsdiagramm:

Konfigurationsbeispiel: Integration von Keycloak für die Authentifizierung mit Apache APISIX

Konfigurieren Sie Keycloak

Beispielcode

curl -XPUT 127.0.0.1:9080/apisix/admin/routes/1 -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
    "uri":"/anything/*",
    "plugins": {
        "openid-connect": {
            "client_id": "myclient",
            "client_secret": "e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq",
            "discovery": "http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration",
            "scope": "openid profile",
            "bearer_only": false,
            "realm": "myrealm",
            "redirect_uri": "http://127.0.0.1:9080/anything/callback",
            "logout_path": "/anything/logout"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "httpbin.org:80":1
        }
    }
}'

Wenn Sie nach erfolgreicher Erstellung der API http://127.0.0.1:9080/anything/test besuchen, werden Sie zur Anmeldeseite von Keycloak weitergeleitet, da Sie sich nicht angemeldet haben:

Geben Sie myuser als Benutzernamen und mypassword als Passwort ein, und Sie werden auf die folgende Seite weitergeleitet.

Besuchen Sie http://127.0.0.1:9080/anything/logout, um sich abzumelden:

Zusammenfassung

Kurz gesagt, der OAuth-Standard ist eine beliebte Lösung für Anwendungen und Benutzer. Er bietet Komfort und Sicherheit, indem er Benutzern ermöglicht, Dienste über mehrere Plattformen hinweg zu nutzen, ohne ihre Anmeldeinformationen preiszugeben. Apache APISIX ist ein beliebtes API-Gateway, das die Integration verschiedener Identitätsanbieter (Keycloak, Ory Hydra, Okta, Auth0 usw.) unterstützt, um Ihre APIs zu schützen.

Weitere Informationen:

• OIDC in Apache APISIX
• Verwenden Sie Keycloak mit API-Gateway, um APIs zu sichern
• APISIX integriert mit Ory Hydra
• APISIX openid-connect plugin