Entschuldigung ... ich möchte diese Frage komplett umformulieren:, und ich habe gefragtdie selbe Fragezur Informationssicherheit jetzt
Das System, an dem ich arbeite, wird eine mobile Anwendung, ein Webportal und eine HTTP-basierte API haben.
Die Frage, auf die ich scheinbar keine Antwort finde:
Muss ich die OpenID Connect- und/oder OAuth-Token-Endpunkte implementieren und Token generieren, auf die der Client zugreifen kann?MeinAPI? Oder ermögliche ich den Clients „irgendwie“ den Zugriff auf die API mithilfe von Token, die vom Open-ID-Anbieter des Benutzers ausgegeben wurden?
Weitere Hintergründe:
Ich möchte Benutzern die Möglichkeit geben, sich mit ihren Google-/Facebook-IDs zu registrieren und anzumelden.
Innerhalb der API speichere ich eine Benutzertabelle mit einigen Attributen, minimal, weil ich nicht mehr als dies brauche, aber im Wesentlichen:
Tabelle Benutzer:
- uid
- realer_Name
- Kontaktnummer
- E-Mail-Adresse
- ist_aktiv
- habe_Administratorrechte
Ich würde auch eine Tabelle für die Open-IDs der Benutzer einrichten, etwa so:
Tabelle open_ids:
- uid
- user_id (Referenzen users(uid)
- open_id
(damit ein Benutzer jede seiner Open-IDs verwenden kann, die er seinem Konto zuordnen möchte)
An anderer Stelle verweise ich auf die Benutzer-ID, zB:
Tabelle foo:
- uid
- bar
- bla
- last_modified_by_user_id (Verweist auf users(uid))
Derzeit habe ich in meinem Test-Setup eine Tabelle „Passwörter“, z. B.:
Tabelle Passwörter:
- uid
- user_id (Referenziert users(uid))
- password_hash
(Hinweis: Die Idee ist, diese Tabelle bald loszuwerden und stattdessen open_id zu verwenden. Welche Bibliotheken ich jedoch auswähle, hängt stark davon ab, welche Funktionen ich implementiere und was ich aus externen Quellen verwende.)
Ich nehme an, dass ich die Zugriffstoken speichern muss, da ich Benutzerdaten, die sich bereits in ihren Social-Service-Profilen befinden, nicht duplizieren möchte und für jeden Benutzer von Zeit zu Zeit auf diese Dienste zugreifen muss. Aber wie bekomme ich das Zugriffstoken vom Client (bei dem sich der Benutzer angemeldet hat) zur API (die die gemeinsam genutzte Ressource zwischen den verschiedenen Clients ist)?
Das Problem besteht nicht so sehr darin, das Token vom Client an die API zu senden - ich kann einfach eine Funktion in der API haben, um einen Benutzer und einige andere Endpunkte zu „registrieren“, wenn ein Benutzer authentifiziert wird. Das Problem besteht darin, dass ein Zugriffstoken nur für einen bestimmten Client bestimmt ist.
Angenommen, ich implementiere KEINEN Autorisierungsserver und kann irgendwie die Dienste von Google usw. verwenden: Auf den Entwicklersites, z. B. für Google oder Facebook, kann ich meinen Client registrieren und das Client-Geheimnis/die Client-ID erhalten. Verwende ich dann aber dieselben Client-Anmeldeinformationen SOWOHL vom Client als auch von der API?
Oder werden die Client-Anmeldeinformationen nur von der API gespeichert und der Front-End-Dienst ist bei der Registrierung eines Benutzers als Zwischenschritt von der API abhängig? Das fühlt sich furchtbar gefährlich und unsicher an. Ist die API also in den Augen des OpenID-Anbieters ein weiterer separater Client?
Angenommen, ich muss einen Autorisierungsserver implementieren. Muss ich dann auch ein Open-ID-Anbieter sein? In diesem Fall müsste es wohl OpenID-Connect sein, da ich sowohl Authentifizierung als auch Autorisierung benötige. Aber in diesem Fall weiß ich wirklich nicht, wie ich eine neue Benutzerregistrierung durchführen soll, und die vorherigen Fragen gehen nicht wirklich weg. Es scheint, dass ich den Client verbinden lassen und die Benutzerauthentifizierung/Zugriffs- und ID-Token vom Open IdP abrufen und den Benutzer dann bei der API „registrieren“ können sollte.