Was ist OAuth? So funktionieren OAuth 2.0 und "Mit Google anmelden"

Was ist OAuth 2.0?

OAuth 2.0 ist ein Autorisierungsframework, mit dem Sie einer Anwendung begrenzten, widerrufbaren Zugriff auf Ihre Daten bei einem anderen Dienst geben, ohne Ihr Passwort weiterzugeben. Die App erhält ein befristetes Zugriffstoken statt Ihrer Zugangsdaten. Genau das steckt hinter Buttons wie "Mit Google anmelden".

Ein Alltagsbild hilft. Stellen Sie sich vor, Sie fahren mit dem Auto vor ein Hotel, und ein Parkservice stellt es ab. Ihren Generalschlüssel geben Sie nicht aus der Hand, denn er öffnet auch Kofferraum, Handschuhfach und Motor. Stattdessen übergeben Sie einen Schlüssel, der nur zum Parken taugt.

Genau diese Idee steckt in OAuth. Dabei ist Ihr Generalschlüssel Ihr Passwort. Der Parkschlüssel ist das Zugriffstoken: Es gilt für eine Aufgabe, es läuft ab, und Sie können es jederzeit sperren.

Die IETF hat den Standard als RFC 6749 veröffentlicht. Zudem steht der Name meist für Open Authorization. Wir behandeln hier genau einen Begriff, daher streifen wir Nachbarthemen nur kurz und verlinken sie.

Wie beantwortet das Parkschlüssel Bild die Frage, was ist OAuth?

Stellen Sie sich die Zeit vor OAuth vor. Zum Beispiel wollte eine Budget App die Rechnungen in Ihrem Postfach lesen. Dafür fragte sie nach Ihrer E-Mail Adresse und Ihrem Passwort und meldete sich als Sie an.

Dieses Vorgehen hatte drei große Probleme. Erstens speicherte die App Ihr Passwort, sodass ein Datenleck Ihr ganzes Konto gefährdete. Zweitens konnte die App alles lesen, nicht nur Rechnungen. Drittens ließ sich der Zugriff nur durch ein neues Passwort beenden, und das brach daher alle anderen verbundenen Apps.

OAuth löst alle drei Probleme zugleich. Ihr Passwort bleibt deshalb zwischen Ihnen und dem E-Mail Dienst. Die App erhält stattdessen ein Token, das nur die freigegebenen Rechte trägt. Wenn Sie Ihre Meinung ändern, entfernen Sie also genau diese eine App.

Wer also in einem Satz wissen will, was ist OAuth, bekommt diese Antwort: ein System zur Delegation von Rechten, kein Passwortsystem. Behalten Sie das Schlüsselbild im Kopf, dann ordnen sich die weiteren Begriffe von selbst.

Was ist OAuth 2.0, und welche vier Rollen gibt es?

In jedem OAuth Gespräch tauchen vier Rollen auf. Weil viele sie verwechseln, wirkt die Dokumentation oft verwirrend. Deshalb ordnet die folgende Liste jede Rolle dem Parkschlüssel Bild zu.

• Ressourcenbesitzer: Die Person, der die Daten gehören, also Sie. Im Bild besitzen Sie das Auto.
• Client: Die Anwendung, die Zugriff möchte. Im Bild ist das der Parkservice.
• Autorisierungsserver: Das System, das Sie prüft, Ihre Zustimmung einholt und Tokens ausstellt. Im Bild ist es die Schlüsselausgabe des Hotels.
• Ressourcenserver: Der Dienst, der die geschützten Daten hält, meist eine API. Im Bild entspricht er dem Auto.

In der Praxis laufen Autorisierungsserver und Ressourcenserver in kleinen Produkten oft im selben Unternehmen. Große Anbieter trennen sie dagegen meist. Wenn Sie wissen möchten, welche Schnittstelle der Ressourcenserver anbietet, hilft unser Artikel zur Frage, was eine API ist.

Außerdem gibt es zwei Arten von Clients. Erstens läuft ein vertraulicher Client auf einem Server und kann ein Geheimnis sicher aufbewahren. Zweitens läuft ein öffentlicher Client läuft im Browser oder auf dem Handy und kann kein Geheimnis verstecken. Dieser Unterschied entscheidet daher, welchen Ablauf Sie wählen.

Wie funktioniert der Authorization Code Flow Schritt für Schritt?

Also zuerst zum Kern: Der Authorization Code Flow ist heute der gängigste und empfohlene OAuth Ablauf. Die Idee ist einfach: Das Token reist nie durch die Adresszeile des Browsers. Zuerst kommt ein kurzlebiger Code, dann tauscht die App ihn über einen Hintergrundkanal gegen das Token.

1. Zunächst klickt ein Nutzer in der App auf einen Button wie "Mit Google anmelden".
2. Danach leitet die App den Nutzer zum Autorisierungsserver weiter und nennt die gewünschten Rechte.
3. Dort weist sich der Nutzer aus und stimmt der Anfrage zu oder lehnt sie ab.
4. Anschließend schickt der Server den Browser zur registrierten Adresse der App zurück, mit einem kurzlebigen Code im Gepäck.
5. Jetzt spricht die App direkt mit dem Server und tauscht den Code gegen ein Zugriffstoken.
6. Schließlich legt die App das Token dem Ressourcenserver vor und erhält die freigegebenen Daten.

Die Schritte vier und fünf sind entscheidend. Denn der Code gilt nur einmal und verfällt schnell. Das Token läuft nie durch den Browser, daher gelangt es viel schwerer in Verlauf, Logs oder Referrer.

Den genauen Wortlaut finden Sie im Abschnitt zum Authorization Code in RFC 6749. Für die tägliche Arbeit genügt allerdings meist der gedankliche Ablauf.

Was ist PKCE und warum brauchen Sie es?

PKCE, gesprochen "pixie", steht für Proof Key for Code Exchange. Das Verfahren steht in RFC 7636. Sein Ziel ist klar: Selbst wenn ein Angreifer den Code auf dem Rückweg abfängt, kann er ihn nicht in ein Token umwandeln.

Das Prinzip funktioniert so. Zunächst erzeugt die App vor dem Start ein zufälliges Geheimnis. Danach schickt sie nur einen Fingerabdruck davon an den Autorisierungsserver. Beim späteren Tausch legt sie dann das Geheimnis selbst vor. Der Server vergleicht beides und lehnt somit den Tausch bei Abweichung ab.

Wer den Code stiehlt, aber das Geheimnis nicht kennt, erhält also nichts Brauchbares. Zum Beispiel gilt beim Paketschein: Nur wer den Schein hat, holt das Paket ab.

Früher empfahl man PKCE vor allem für mobile Apps und Browser Apps. Heute raten dagegen aktuelle Sicherheitsleitlinien dazu für jeden Client, der den Authorization Code Flow nutzt, auch für vertrauliche. Der Aufwand ist gering, daher schließen Sie damit eine ganze Angriffsklasse.

Was bedeuten Scopes und der Zustimmungsbildschirm?

Ein Scope ist ein Rechtelabel, das beschreibt, auf welche Daten und Aktionen eine App zugreifen möchte. Zum Beispiel sind "Profil lesen" und "Termin im Kalender anlegen" zwei verschiedene Scopes. Die App listet sie in ihrer Anfrage auf, und der Anbieter zeigt sie Ihnen auf dem Zustimmungsbildschirm.

Auf diesem Bildschirm schneiden Sie den Parkschlüssel zurecht. Konkret wird jede Zeile, die Sie dort lesen, zu einem Recht im Token. Deshalb lohnt es sich, hinzuschauen, statt nur zu klicken.

Für Entwickler gilt deshalb das Prinzip der minimalen Rechte. Wenn das Basisprofil zur Anmeldung reicht, fragen Sie nicht nach Kontakten oder Dateien. Zu viele Rechte senken das Vertrauen der Nutzer, und bei einem Token Leck wächst der Schaden.

Außerdem sollten Inhaber wissen: Anbieter prüfen Scope Anfragen mitunter. Sensible Scopes können zudem zusätzliche Verifizierung verlangen. Die aktuellen Anforderungen entnehmen Sie der offiziellen Entwicklerdokumentation des Anbieters.

Worin unterscheiden sich Zugriffstoken und Refresh Token?

Das Zugriffstoken ist der Parkschlüssel, den Sie bei jeder Anfrage dem Ressourcenserver zeigen. Wir wollen es kurzlebig, denn so hat ein Diebstahl begrenzte Folgen. Das Refresh Token ist ein langlebiger und deutlich sensiblerer Schlüssel, mit dem Sie neue Zugriffstokens holen.

Im Bild ist das Zugriffstoken der tägliche Parkschlüssel und das Refresh Token das Recht, einen neuen anzufertigen. Geht der erste Schlüssel verloren, läuft er also bald ab. Geht der zweite verloren, kann ein Angreifer immer neue Schlüssel erzeugen, deshalb brauchen Sie dafür eine sichere Ablage.

OAuth schreibt das Tokenformat nicht vor. Konkret stellen manche Anbieter undurchsichtige Zufallszeichen aus. Andere nutzen signierte Tokens, die Informationen enthalten. Dieses signierte Format haben wir separat erklärt, unser JWT Beitrag behandelt Aufbau und Prüfung, daher wiederholen wir es hier nicht.

In der Praxis gilt eine einfache Regel. Schreiben Sie ein Zugriffstoken nie in eine URL, ein Log oder eine Fehlermeldung. Speichern Sie Refresh Tokens nur serverseitig in einem verschlüsselten Speicher. Außerdem entwerten Sie beide, sobald ein Nutzer das Konto trennt.

Sind Authentifizierung und Autorisierung dasselbe?

Nein, und genau hier beginnt daher das häufigste Missverständnis. Erstens beantwortet Authentifizierung die Frage "Wer ist diese Person?". Zweitens beantwortet Autorisierung die Frage "Worauf darf diese Person oder App zugreifen?".

Wer sich fragt, was ist OAuth, nimmt oft an, es regle die Anmeldung. OAuth 2.0 zielt aber viel stärker auf die zweite Frage. Ein Zugriffstoken sagt "diese App darf den Kalender lesen". Es sagt allerdings nicht "vor Ihnen sitzt Alex". Wer ein reines OAuth Token als Identitätsnachweis behandelt, baut daher ein schwaches Design.

Zum Beispiel verrät eine Hotelkarte der Tür, wer hineindarf. Wer die Karte trägt, verrät sie nicht. Die Karte gibt Zugang, doch sie zeigt keine Identität, also keinen Namen.

Für die Anmeldung schließt OpenID Connect diese Lücke. Diese Schicht behandeln wir im nächsten Abschnitt.

Was ergänzt OpenID Connect auf OAuth 2.0?

Kurz gesagt ist OpenID Connect (OIDC) eine Identitätsschicht auf Basis von OAuth 2.0. Die OpenID Foundation beschreibt den Standard und passende Bibliotheken. Wo OAuth ein Zugriffstoken liefert, fügt OIDC dann ein ID Token hinzu.

Das ID Token ist ein signierter Nachweis. Es nennt, wer der Nutzer ist, wann und wie er sich angemeldet hat und für welche App es gilt. Die App prüft die Signatur und folgert somit: Diese Sitzung hat wirklich bei diesem Anbieter begonnen.

OIDC bringt zudem einen standardisierten Endpunkt für Nutzerinfos und Standard Scopes mit. Zum Beispiel kommen Profil und E-Mail bei jedem Anbieter unter denselben Namen an. Somit schreiben Sie nicht für jeden Anbieter eigenen Code.

Anders gesagt: Wenn Sie einen Button "Mit Google anmelden" bauen, nutzen Sie technisch OpenID Connect, und OAuth 2.0 trägt es darunter. Plant Ihr Team einen Social Login, lautet der richtige Begriff meist "OIDC Anmeldung".

Wie unterscheiden sich OAuth, OpenID Connect, SAML und Passkeys?

Diese vier Begriffe werden oft vermischt, weil alle mit Anmeldung und Zugriff zu tun haben. Dennoch löst jeder ein anderes Problem. Daher zeigt die Tabelle den Unterschied auf einen Blick.

Wichtig ist: Es handelt sich um Schichten, nicht um Rivalen. Ein Anbieter kann Nutzer per Passkey prüfen und Ihnen die Identität dann per OIDC übergeben. Die Passkey Seite erklären wir in unserem Passkey Ratgeber.

SAML ist älter und nutzt XML, daher begegnet es Ihnen vor allem im Unternehmensumfeld. Andererseits basiert OIDC auf JSON und passt natürlicher zu Web und Mobile. Richtet sich Ihr Angebot an Privatkunden, ist OIDC deshalb meist der naheliegende Einstieg.

Was passiert hinter dem Button "Mit Google anmelden"?

Folgen wir einem Besucher vom Klick bis zur fertigen Anmeldung. Dieser Abschnitt fügt die bisherigen Bausteine zu einem Szenario zusammen. Dabei ist es ein Beispiel und beschreibt keine aktuelle Oberfläche eines Anbieters pixelgenau.

1. Zunächst klickt der Besucher auf Ihren Anmeldebutton.
2. Dann erzeugt Ihre Seite einen zufälligen State Wert und ein PKCE Geheimnis und merkt sich beides in der Sitzung.
3. Danach öffnet der Browser die Anmelde- und Zustimmungsseite des Anbieters.
4. Dort weist sich der Besucher aus, prüft die angefragten Rechte und stimmt zu.
5. Anschließend schickt der Anbieter den Besucher mit Code und State Wert zu Ihrer Seite zurück.
6. Dann vergleicht Ihr Server den State Wert und tauscht Code und Geheimnis von Server zu Server gegen Tokens.
7. Schließlich validiert Ihr Server das ID Token, ordnet den Nutzer zu oder legt ihn an und startet die eigene Sitzung.

Beachten Sie, dass zwei getrennte Sitzungen existieren. Die Sitzung beim Anbieter und die Sitzung auf Ihrer Seite hängen nicht voneinander ab. Der Anbieter sagt also nur "ich habe diese Person erkannt", und Ihre eigene Sitzung verwalten Sie selbst.

Den State Wert erzeugen Sie in Schritt zwei und erhalten ihn in Schritt fünf zurück. Stimmen die Werte nicht überein, lehnen Sie die Anfrage ab. Diese kleine Prüfung stoppt daher gefälschte Weiterleitungen.

Welche Sicherheitsfehler passieren bei OAuth 2.0 am häufigsten?

OAuth selbst ist ein solides Framework, allerdings öffnet eine nachlässige Umsetzung ernste Lücken. Die IETF hat bekannte Angriffe und Gegenmaßnahmen im OAuth 2.0 Security Best Current Practice (RFC 9700) gesammelt. Wir fassen die Fehler zusammen, die uns in der Praxis am häufigsten begegnen.

• Lockere Prüfung der Weiterleitungsadresse: Stimmen registrierte und eingehende Adresse nicht exakt überein, kann ein Angreifer den Code umleiten. Verlangen Sie exakte Übereinstimmung und verzichten Sie auf Platzhalter.
• Zu weit gefasste Scopes: Unnötige Rechte vergrößern den Schaden bei einem Leck.
• Token Leck: Tokens in Logs, Fehlerseiten, URLs oder im Browserspeicher laden zum Diebstahl ein.
• State Wert ausgelassen: Abläufe ohne ihn bleiben für gefälschte Anfragen offen.
• Geheimnis im Client Code: Alles, was im Browser landet, ist lesbar, ein Geheimnis lässt sich dort nicht verstecken.

Konkret wenden die meisten Punkte allgemeine Web Sicherheitsprinzipien auf OAuth an. Außerdem zeigen das größere Bild unser OWASP Top 10 Ratgeber und der Beitrag zu SSL Zertifikaten und HTTPS, der den Schutz auf dem Transportweg erklärt.

Warum rät man vom Implicit Flow heute ab?

Der Implicit Flow kam mit dem ersten OAuth 2.0 Release, denn er zielte auf Browser Apps. Nach der Zustimmung lieferte er das Token direkt im Fragment der Adresszeile zurück. Einen Code und einen Hintergrundkanal gab es dabei nicht.

Dieses Design setzte folglich das Token dem Browserverlauf, Erweiterungen und anderen Skripten auf der Seite aus. Außerdem ließ sich schwer prüfen, für wen das Token gedacht war. Das Dokument zu den Sicherheitsempfehlungen rät vom Implicit Flow und ähnlichen Antworttypen ab, die Tokens direkt liefern.

Was nutzen Sie stattdessen? Selbst für Browser Apps gilt der Authorization Code Flow mit PKCE. Ihre App bleibt somit auch ohne Serverteil sicher. Übernehmen Sie ein älteres System, gehört das Abschalten des Implicit Flow ganz oben auf die Prüfliste.

Wir betonen das, weil alte Tutorials und Beispielprojekte das Muster noch zeigen. Vergleichen Sie daher Gelerntes aus älteren Quellen mit aktuellen Leitlinien, bevor Sie es übernehmen.

Welchen OAuth Ablauf wählen Sie wann?

OAuth ist nicht ein einziger Ablauf. Es definiert mehrere Abläufe für verschiedene Clients. Ihre Wahl hängt also davon ab, wo die App läuft und ob ein Nutzer beteiligt ist. Die Tabelle beschleunigt dann die Entscheidung.

Bewährte Vorgehen für native Apps sammelt RFC 8252. Dort steht außerdem, warum der Systembrowser einer eingebetteten Ansicht überlegen ist.

Auch der alte Passwort Ablauf, bei dem der Client Benutzername und Passwort direkt einsammelt, ist nicht mehr empfohlen. Er bringt nämlich genau das Problem zurück, das OAuth lösen wollte: die Weitergabe des Passworts an Dritte.

Wie binden Sie einen Social Login sicher in eine Firmenwebsite ein?

Ein Social Login verkürzt Registrierungsformulare und senkt die Passwortmüdigkeit. Allerdings ist er keine Funktion zum Einrichten und Vergessen. Deshalb teilen wir die Checkliste, die unser Team in Projekten nutzt.

• Prüfen Sie zunächst den Bedarf: Bei welchen Anbietern haben Ihre Nutzer überhaupt ein Konto?
• Fragen Sie nur die nötigen Scopes an, E-Mail und Basisprofil genügen oft.
• Nutzen Sie den Authorization Code Flow mit PKCE und lassen Sie den Implicit Flow aus.
• Dann registrieren Sie Weiterleitungsadressen mit exakter Übereinstimmung und trennen Sie Test und Live.
• Erzeugen Sie für jede Anfrage einen State Wert und prüfen Sie ihn bei der Rückkehr.
• Außerdem kontrollieren Sie Signatur, Zielgruppe und Ablauf des ID Tokens auf dem Server.
• Halten Sie Tokens aus den Logs heraus und speichern Sie Refresh Tokens verschlüsselt.
• Bieten Sie Nutzern an, die Verbindung zu trennen und ihr Konto zu löschen.
• Entwerfen Sie Regeln zum Zusammenführen von Konten, bevor Sie der E-Mail Adresse eines Anbieters vertrauen.
• Lassen Sie einen alternativen Anmeldeweg offen, denn wer sein Anbieterkonto verliert, verliert sonst auch Ihre Seite.

Denken Sie außerdem an den Datenschutz. Ihre Datenschutzerklärung muss dann nennen, welche Felder Sie vom Anbieter erhalten und warum Sie sie speichern. Den Rahmen fasst unser Leitfaden für eine DSGVO konforme Website zusammen. Dieser Beitrag ist keine Rechtsberatung, verbindliche Antworten erhalten Sie bei Ihrer Rechtsberatung.

Stellen Sie zudem sicher, dass Ihre Anmeldeseite eine gesicherte Verbindung nutzt. Unser SSL Check prüft das in Sekunden. Bieten Sie daneben Passwort Anmeldung an, zeigt der Passwort Generator Ihren Nutzern, wie ein starkes Passwort aussieht.

Was bringt ein Social Login für Nutzererlebnis und Conversion?

Ein Social Login nimmt Reibung aus dem Registrierungsformular. Der Nutzer erfindet also kein Passwort, wartet nicht auf eine Bestätigungsmail und ist mit einem Tipp drin. Auf dem Handy fällt der Unterschied besonders auf.

Allerdings passt er nicht für jedes Unternehmen. Erstens meiden manche Zielgruppen die Anmeldung mit einem Social Konto. Zweitens trennen Nutzer in einigen Branchen lieber Arbeit und Privates. Daher funktioniert ein Social Login neben der E-Mail Anmeldung oder einem Passkey besser als allein.

Entscheiden Sie deshalb nicht ohne Messung. Beobachten Sie vor dem Start die Abschlussquote der Registrierung, die erste Aktion nach der Anmeldung und die Supportanfragen. Wie Sie messen, hängt zudem vom Aufbau Ihrer Seite ab.

Wir nennen hier keine Zahlen, denn die Ergebnisse schwanken stark nach Branche, Zielgruppe und Oberfläche. Ein kleiner Test mit Ihren eigenen Daten schlägt daher jede pauschale Behauptung.

Wie gehen Tokens mit Laufzeit und Widerruf um?

Die praktischste Sicherheitsantwort auf die Frage, was ist OAuth, lautet: Tokens sind zeitlich begrenzt. Ein Zugriffstoken läuft nach kurzer Zeit von selbst ab. Danach fordert die App mit dem Refresh Token ein frisches an.

Der Nutzen ist klar: Selbst ein gestohlenes Token wird bald wertlos. Refresh Tokens sind deutlich wertvoller, deshalb schützen Anbieter sie mit zusätzlichen Regeln. Zum Beispiel kann ein Anbieter bei jeder Nutzung ein neues Refresh Token ausgeben oder alle sperren, sobald er verdächtige Nutzung bemerkt.

Der Widerruf funktioniert nämlich in zwei Richtungen. Zunächst kann der Nutzer die App in den Kontoeinstellungen des Anbieters entfernen. Außerdem kann die App beim Löschen eines Nutzers oder beim Trennen dem Anbieter melden, dass er Tokens entwerten soll. Apps, die den zweiten Schritt auslassen, behalten gültige Tokens, obwohl der Nutzer längst gegangen ist.

Allerdings unterscheiden sich die Standardlaufzeiten je nach Anbieter. Merken Sie sich deshalb keine feste Zahl, sondern lesen Sie die Dokumentation und stellen Sie die Laufzeiten nach Ihrem eigenen Risiko ein.

Wofür nutzt man OAuth außer für Social Login?

Der Social Login ist nur die sichtbarste Anwendung. Denn OAuth taucht überall auf, wo eine App im Namen eines Nutzers die API eines anderen Dienstes erreichen muss. Die Anmeldung ist nur ein Fall davon.

• Eine Kalender App liest Terminanfragen aus einem E-Mail Dienst.
• Eine Buchhaltungssoftware holt Umsätze von einem Zahlungsdienst.
• Ein Reporting Dashboard liest mit Erlaubnis des Nutzers Daten eines Werbekontos.
• Ein Automatisierungstool legt für Sie Einträge in einem Dateidienst an.

In jedem Fall gilt dieselbe Idee: Der Nutzer gibt kein Passwort heraus, sondern nur ein Recht für eine Aufgabe. Für Unternehmen heißt das konkret, dass Sie Integrationen bauen können, ohne Kunden oder Mitarbeiter nach Zugangsdaten zu fragen.

Für Integrationen von Server zu Server ohne Nutzer verwenden Sie den Client Credentials Ablauf. Die Logik dahinter erklärt unser Artikel zur Frage, was eine API ist, und der Vergleich von GraphQL und REST rundet das Bild zu Datenzugriffsmodellen ab.

Welche Missverständnisse zu OAuth sollten Sie vermeiden?

Wer lernt, was ist OAuth, stolpert meist über dieselben Irrtümer. Räumen Sie sie früh auf, dann werden Dokumentation und Teamgespräche leichter.

• "OAuth ist ein Verschlüsselungsverfahren." Nein, es ist ein Ablauf zur Delegation. HTTPS schützt die Daten auf dem Weg.
• "Ein Zugriffstoken beweist die Identität." Nein, es zeigt ein Recht, nicht die Person. Für Identität brauchen Sie OpenID Connect.
• "Mit Social Login ist meine Sicherheitsarbeit erledigt." Nein, nur die Passwortspeicherung entfällt. Sitzungen und Token Ablage bleiben Ihre Aufgabe.
• "Mit einer Bibliothek brauche ich keine Konfiguration." Nein, Weiterleitungsadressen und Scopes liegen weiter in Ihrer Verantwortung.
• "OAuth 2.0 und OAuth 1.0 sind dasselbe." Nein, es sind verschiedene Protokolle, und 2.0 ist heute die gängige Version.

Jedes Missverständnis kann dennoch zur Schwachstelle werden. Zum Beispiel könnte eine App, die ein Token mit Identität verwechselt, ein Token für eine andere App akzeptieren. Überspringen Sie deshalb nie die Prüfung der Zielgruppe.

Wie registriert sich ein Client, und was ist eine Client ID?

Zunächst gilt: Bevor eine App sich erstmals mit einem Anbieter verbindet, registriert sie sich. Sie nennen dem Anbieter App Namen, App Typ und erlaubte Rückkehradressen. Dafür erhalten Sie dann eine Client ID. Vertrauliche Clients bekommen zusätzlich ein Client Secret.

Die Client ID darf öffentlich sein, sie ähnelt dem Benutzernamen Ihrer App. Das Secret verhält sich dagegen wie ein Passwort. Legen Sie es in einer Umgebungsvariable des Servers oder einem Secrets Manager ab und committen Sie es nie ins Code Repository.

Die registrierten Rückkehradressen sind das kritischste Feld, denn der Anbieter sendet Codes nur an Adressen dieser Liste. Halten Sie die Liste daher kurz und registrieren Sie lokale Testadressen getrennt von Ihrer Live App.

Entwickler Dashboards und Menünamen der Anbieter können sich nämlich ändern. Folgen Sie deshalb den Schritten der aktuellen Entwicklerdokumentation, statt sich auf exakte Bildschirmnamen zu verlassen. Als Domain Beispiel nutzen wir nur Platzhalter wie example.com.

Was sollten Inhaber aus der Frage, was ist OAuth, mitnehmen?

Auch ohne technisches Team wirkt dieses Konzept auf Geschäftsentscheidungen. Sie müssen keinen Code schreiben, sondern die richtigen Fragen stellen. Die folgenden Fragen helfen im Gespräch mit Entwicklern oder einer Agentur.

• Welche Anbieter bieten wir an, und warum genau diese?
• Welche Daten erheben wir, und welche Felder nutzen wir wirklich?
• Wo speichern wir Tokens, und wer kommt daran?
• Was passiert, wenn ein Nutzer die Verbindung trennen will?
• Wie lautet unser Plan B, wenn ein Anbieter Bedingungen ändert oder unseren Zugriff einschränkt?

Bleiben die Antworten vage, ist die Integration also noch nicht reif. Ein Social Login bindet Ihr Geschäft an die Regeln eines anderen Unternehmens. Ein Anbieter kann seine Einstellungen eines Tages ändern, daher ist es klug, nicht von einem einzigen Anbieter abzuhängen.

Schließlich bleibt die Verantwortung für die Daten bei Ihnen. Jedes personenbezogene Feld, das Sie vom Anbieter erhalten, fällt unter die Datenschutzpflichten Ihrer Seite. Erheben Sie nur, was Sie brauchen, und erklären Sie dem Nutzer den Grund.

Was ist OAuth, und wo beginnen Sie mit dem Lernen?

Für Einsteiger führt der effizienteste Weg über das Konzept. Denn sobald Rollen, Authorization Code Flow und Scopes sitzen, werden die Protokolldetails leichter. Beobachten Sie den Ablauf danach in einer kleinen Test App.

1. Erklären Sie das Parkschlüssel Bild und die vier Rollen in eigenen Worten.
2. Zeichnen Sie den Authorization Code Flow auf Papier und begründen Sie jeden Pfeil.
3. Lernen Sie, welchen Angriff PKCE schließt.
4. Lesen Sie die Entwicklerdokumentation eines Anbieters und registrieren Sie eine Test App.
5. Machen Sie aus dem Dokument zu den Sicherheitsempfehlungen Ihre eigene Checkliste.

Die Primärquellen sind für technische Leser klar genug. Sie müssen die Standards nicht wortwörtlich auswendig lernen. Es genügt zu wissen, welches Dokument welche Frage beantwortet.

Möchten Sie Anmeldung oder Integrationen in ein Produkt einbauen und die Arbeit abgeben, erreichen Sie uns über unsere Leistung individuelle Softwareentwicklung. Dabei planen wir Einrichtung, Sicherheitsprüfung und Dokumentation gemeinsam. Verwirren Sie Cloud Modelle, ist unser Vergleich von IaaS, PaaS und SaaS ein guter erster Schritt.