OAUTH2 Server selber machen oder in Cloud mieten?

[psycodad]

Hallo,
Wir möchten gerne einige unserer rest-api's der Webanwendung eines Partner zur Verfügung stellen. Die User der Partner-Webanwendung sollen unsere API benützen können. Dazu müssen die User sich bei uns identifizieren. Wenn der User bei uns nicht existiert, dann muss er sich zuerst bei uns registrieren.
Soweit ich mich eingelesen habe wird das heutzutage über einen OAUTH2 Server abgehandelt. Dabei stellt sich wieder die Frage, ob man den selber machen muss oder ob es besser ist, dazu einen Cloud Anbieter zu verwenden.

Zum Selber Machen habe ich folgendes gefunden:
https://www.esegece.com/websockets/h.../oauth2-server
Als Cloud-Lösung habe ich folgendes gegoogelt:
https://auth0.com/


Ich bin mir nicht sicher was besser ist. Da wir schon über 1000ende User verfügen tendiere ich dazu, es selber zu machen. Wir verfügen über eine eigene Citrix VM infrastruktur in einem eingemieteten Rechenzentrum. Wir können also also alles selber hosten.

Oder:
Ich könnte das ganze auch einfach halten. Der Partner kriegt ein fixes AppToken, dass er beim Aufruf unserer Rest-API mitliefert. Er ruft dann einen Rest-Endpunkt auf mit der E-Mail Adresse des Users als Parameter und ich liefere zurück ob der User bei uns existiert oder nicht. Wenn nicht soll der User sich bei uns auf der Webseite registrieren gehen.
Ich bin mir nicht sicher, ob ich mir das etwas zu einfach vorstelle..

Hat das schon mal jemand gemacht?

Ich würde gerne wissen, wie ihr das angehen würdet.

[Rollo62]

Wäre das auch eine Option ?
https://github.com/thephpleague/oauth2-server

[generic]

OAuth Server gibt es viele:
https://www.keycloak.org/
oder
https://www.ory.sh/hydra

Wenn du selbst was in C# programmieren willst/musst weil deine UserDB speziell ist geht auch:
https://identityserver4.readthedocs.io/en/latest/

[mjustin]

Die zweite Methode ist meiner Meinung nach ausreichend, OAuth ist nicht nötig. Anstatt des fixen Tokens können auch zeitbasierte Auth-Codes (so wie bei den Authenticator Apps) verwendet werden, dann kann kein Zugriff durch ein abgefangenes Token mehr stattfinden.

[Phoenix]

Zitat von psycodad:

Hat das schon mal jemand gemacht?

Ja, das ist ein großteil von dem, mit dem ich meine Brötchen verdiene.

Du willst OAuth 2.0 / OIDC nicht selber bauen. Unter gar keinen Umständen. Da kann man so viel falsch machen was hinterher echt ein Security-Problem ist und Dich bei Heise Security auf die Frontpage bringen kann, das Risiko ist da einfach zu hoch.

Einkaufen / Mieten kannst Du das bei Auth0 oder auch Okta (da gehört Auth0 inzwischen auch dazu), und bei allen großen Cloud-Anbietern (Azure AD, AWS Identity, Google Identity).
Nachteil: Wenn überhaupt kannst Du nur ganz wenig am UI anpassen (ggf. Namen und Logos). Bei Auth0 / Okta ist etwas mehr möglich, aber auch nur sehr begrenzt.
Vorteil: Du kannst nicht viel anpassen und damit ggf. kaputt machen

Wenn Du es selber hosten willst würde ich zu fertigen Produkten raten. Keycloak wurde schon genannt und ist unserer Meinung nach eine sehr gute Idee.
Du kannst das UI (nicht die Funktionalität) durch Templates nahezu beliebig anpassen, und es bietet für alle Management-Funktion auch eine eigene REST-Api um z.B. User zu verwalten und Features zu konfigurieren. Hier muss man halt regelmäßig das System aktualisieren, aber der Aufwand hier hält sich in Grenzen.

Nur wenn das aufgrund irgendwelcher zwingend(!) benötigter Spezialfunktionen nicht möglich ist, würde ich da selber Hand anlegen. IdentityServer wurde auch schon genannt, der 4er ist allerdings abgekündigt und bekommt nur noch bis Ende 2022 Bugfixes. Der 5er ist dann kostenpflichtig und das ist auch nicht wirklich billig. Openiddict ist da auch eine Bibliothek die man nehmen kann, aber die können eben nur das reine OAuth 2.0 / OIDC Protokoll, alles andere drumrum (user store, Login-UI, Absicherung des UIs durch CSRF-Tokens etc., Multifaktor-Support, User-Registrierung, Password-Reset etc.pp.) muss man alles manuell dazu bauen. So Identity-Provider Projekte sind in aller Regel mehrere Wochen lang, und erfordern dazu dann regelmäßige Wartung (Packages updaten etc.), damit man Bugfixes in Bibliotheken auch übernimmt.

Und diese Empfehlungen oben geben wir auch unseren Kunden, Obwohl wir mit selber machen am meisten verdienen würden und mit Cloud-Lösung shoppen am wenigsten. Aber am Ende gehts hier um Sicherheit, und die Kernkompetenz der Kunden liegt in aller Regel nicht im IdP-Umfeld sondern in anderen Business-Sachen

[Rollo62]

Zitat von Phoenix:

Du willst OAuth 2.0 / OIDC nicht selber bauen. Unter gar keinen Umständen.

Ich bin da ja völlig deiner Meinung.
Trotzdem kommt es doch immer ein bischen auf den UseCase an, oder nicht ?

Für Banking, ja das sollte man outsourcen, keine Frage.

Wenn ich aber z.B. kostenlose Standard-Services anbieten möchte, für Apps die B2C gehen,
da sind > 150-300 EUR / Monat für ein paar Tausend User schon ärgerlich.
Allerhöchste Sicherheit würde ich da nicht unbedingt brauchen.
Die Preismodelle sind meistens etwas undurchsichtig, um das vorsichtig zu sagen,
was wird berechnet, die reine Nutzung (per Zugriff) oder nur die Listung der Nutzer (per User) ?
So können viele, inaktive User die nur mal den Service auschecken auch eine Menge Geld kosten, und wieder rauswerfen möchte man die auch nicht.

Das blöde bei den Cloud-Services ist, dass die erstmal kostenlos sind um dich anzufüttern,
aber wenn dan endlich mal was los ist auf deinem Service, dann steigen auch die Preise rasant an.
Wenn die Monetarisierung im B2C erstmal gering und unsicher ist springe ich ungerne auf solche Dienste.

Gibt es da nicht auch einen sinnvollen Zwischenweg, mit dem man Kosten sparen oder zumindest planbar machen kann ?

[Phoenix]

Zitat von Rollo62:

Gibt es da nicht auch einen sinnvollen Zwischenweg, mit dem man Kosten sparen oder zumindest planbar machen kann ?

Also Azure AD B2C (also die Consumer-Seite) ist z.B. kostenlos bis 50.000 User. Selbst danach ist das pricing noch in Ordnung.
Und wenn man mit mehr als 50.000 User nicht so viel verdient um das zu bezahlen, sollte man sich vielleicht das eigene Business-Modell nochmal angucken

Aber ja, es ist nicht jedermans Sache sowas in der Cloud als fertig zu shoppen, oder man hat etwas weitergehende Bedürfnisse was die Anpassbarkeit angeht (das geht da ja nur stark begrenzt).

Deswegen hatte ich ja auch nochmal Keycloak genannt: Ist Open-Source, darf kostenlos eingesetzt werden, muss man halt selber hosten, aber es ist ein vollwertiger Identity Provider mit UI, eigener Datenhaltung, Mehrfaktor-Feature etc. in einem fertigen Paket. Ist ein Java-Teil, also ein wenig mit Java-VM Optimierung sollte man sich auskennen wenn man das etwas größer skalieren möchte, aber da kann man sich einfacher reinfuchsen als in die OIDC - Spezifikation Ansonsten gibts hier auch schon fertige Docker-Images, wenn man z.B. schon ne eigene Container-Plattform wie einen Kubernetes-Cluster hat. Das Docker-Image ist auch zom Lokal austesten genial. Ein docker run Aufruf und man hat den fertig am Laufen und kann sich mal durchklicken. Wenn man kommerziellen Support dafür will, kann man den von RedHat mit dem RedHat Single-Sign-On Produkt auch einkaufen.

Edit Ergänzung:
https://docs.microsoft.com/en-us/azu...ry-b2c/billing
Berechnet werden hier MAU's, also Monatliche Aktive User. Das heisst die ersten 50.000 User, die sich in einem Monat einloggen sind frei. Dabei zählt aber der Benutzer, und nicht jeder Login-Prozess. Also wenn sich alle 50.000 User, die kostenlos sind, jeden Tag 5x einloggen kostet das keinen Cent extra.
Danach kostet ein MAU €0.002741, also die nächsten 10.000 User die sich in einem Monat einloggen würden 27,41 € kosten, weitere 50.000 lägen dann bei 137,05 €.

[Rollo62]

Zitat von Phoenix:

Zitat von Rollo62:

Gibt es da nicht auch einen sinnvollen Zwischenweg, mit dem man Kosten sparen oder zumindest planbar machen kann ?

Also Azure AD B2C (also die Consumer-Seite) ist z.B. kostenlos bis 50.000 User. Selbst danach ist das pricing noch in Ordnung.

Ja stimmt, dankesehr für den Tipp, Azure hatte ich gar nicht auf dem Schirm.
Kommt in der Auflistung nur unter MS im Unterpunkt vor.
Das scheinen ja faire Konditionen zu sein.

Zitat von Phoenix:

Und wenn man mit mehr als 50.000 User nicht so viel verdient um das zu bezahlen, sollte man sich vielleicht das eigene Business-Modell nochmal angucken

Auch richtig, aber "Facebook mit Milliarden Usern ist vielleicht nicht das einzige Businessmodell.
Es könnte statt einmal 50000 Nutzer auch Modelle geben die z.B. "einen" Service an 10 x 5000 Nutzer anbietet,
und dann über die Partner versucht hochzuskalieren.
Dabei würde man nicht von einer großen Anzahl profitieren können, es sei denn das Auth wäre Mandantenfähig.

Zitat von Phoenix:

Aber ja, es ist nicht jedermans Sache sowas in der Cloud als fertig zu shoppen, oder man hat etwas weitergehende Bedürfnisse was die Anpassbarkeit angeht (das geht da ja nur stark begrenzt).

Doch im Prinzip schon, nur man bindet sich dann immer extrem an seine Provider.
Ich hatte auch mal mir "Parse" angefangen, als dieses dann plötzlich abgekündigt wurde.
Es scheint immer noch zu Leben, und Community gepflegt, aber wenn man mal damit schlechte Erfahrungen hatte bleibt das im Hinterkopf erhalten.
Auch Google ist für rigoroses rausschmeissen bekannt.
Das sollte man auch immer im Auge behalten, denn Konditionen können sich mal ändern.
Aber ja, das gute, alte M$ ist eigentlich immer sehr fair und zuverlässig was dass betrifft.

In der Regel tendiere ich schon zu Google Firebase, weil dies alles Mögliche abdeckt.
Aber preislich kann Google auch mal gut zuschlagen.

Ich bin eher dafür sich an einen Provider zu binden, statt ein Patchwork aus zig. Providern zu unterhalten,
aber vielleicht bin ich da etwas zu altmodisch (oder bequem)

[psycodad]

Zitat von Rollo62:

Wäre das auch eine Option ?
https://github.com/thephpleague/oauth2-server

Mit PHP hatte ich in der Vergangenheit so meine Probleme bei vielen gleichzeitigen Zugriffen. Will nicht heissen dass PHP schlecht wäre. Ich habes einfach nicht in den Griff gekriegt.

Also eher nicht (für mich).

[psycodad]

Zitat von mjustin:

Die zweite Methode ist meiner Meinung nach ausreichend, OAuth ist nicht nötig. Anstatt des fixen Tokens können auch zeitbasierte Auth-Codes (so wie bei den Authenticator Apps) verwendet werden, dann kann kein Zugriff durch ein abgefangenes Token mehr stattfinden.

Jepp, dahin wird die Reise wahrscheinlich gehen. Die Partnerfirma kriegt von mir Credentials und holt sich damit ein JWT bei uns ab. Damit sollte dann der Zugriff auf unsere API genug sicher sein.