OAUTH2 Server selber machen oder in Cloud mieten?

[psycodad]

Zitat:

Zitat von Phoenix (Beitrag 1494300)

Zitat:

Zitat von Rollo62 (Beitrag 1494298)

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 €.

Ich habe das hier gefunden: https://github.com/paolo-rossi/delphi-jose-jwt . hat da jemand Erfahrung damit?
So wie ich das überflogen habe sollte es reichen, um anhand von Credentials ein bearer jwt zu generieren und validieren.
Wie erwähnt, ich glaube um eine B2B rest-api zu sichern müsste das ausreichen?

[Phoenix]

Zitat:

Zitat von psycodad (Beitrag 1494327)

Ich habe das hier gefunden: https://github.com/paolo-rossi/delphi-jose-jwt . hat da jemand Erfahrung damit?
So wie ich das überflogen habe sollte es reichen, um anhand von Credentials ein bearer jwt zu generieren und validieren.
Wie erwähnt, ich glaube um eine B2B rest-api zu sichern müsste das ausreichen?

Ich mache schon länger kein Delphi mehr, zu dem Lib kann ich Dir daher nicht viel sagen.

Allerdings frage ich mich dann, warum dann überhaupt die Indirektion über das JWT?

Wenn der Kunde eh Credentials bekommt, kann er diese doch dann im Prinzip gleich als Basic-Auth ( also Base64Encode(username:password) ) mitschicken, oder Du generierst anstelle von Username + Password für jeden Kunden direkt einen Api-Key, den er auch als ApiKey-Header mitschickt. Kurzer Lookup in der DB ob der API-Key drin steht (und ggf. basierend darauf die Rechte dieses Users ermitteln), und wuppdi, ist der Aufruf authorisiert.

Ob Du jetzt einen User im Token-Server deaktivierst damit er keine Tokens mehr bekommt oder den API-Key direkt invalidierst schenkt sich da meiner Meinung nach nicht wirklich viel. Und Du musst Dich nicht mit JWT's generieren, signieren und validieren herumschlagen.

[Rollo62]

Zitat:

Zitat von psycodad (Beitrag 1494327)

Ich habe das hier gefunden: https://github.com/paolo-rossi/delphi-jose-jwt . hat da jemand Erfahrung damit?

Die Library ist aktuell und wird auch in vielen Projekten verwendet.

Das bildet aber noch kein komlettes OAuth-System ab.
Aber ja, man kann sich damit was frickeln.
Ob das Sinn mach sei mal dahingestellt, ich tendiere da eher zu kompletten Lösungen die gut gepflegt sind,
statt solche Dinge selbst zu versuchen.

[psycodad]

Zitat:

Zitat von Phoenix (Beitrag 1494332)

Zitat:

Zitat von psycodad (Beitrag 1494327)

Ich habe das hier gefunden: https://github.com/paolo-rossi/delphi-jose-jwt . hat da jemand Erfahrung damit?
So wie ich das überflogen habe sollte es reichen, um anhand von Credentials ein bearer jwt zu generieren und validieren.
Wie erwähnt, ich glaube um eine B2B rest-api zu sichern müsste das ausreichen?

Ich mache schon länger kein Delphi mehr, zu dem Lib kann ich Dir daher nicht viel sagen.

Allerdings frage ich mich dann, warum dann überhaupt die Indirektion über das JWT?

Wenn der Kunde eh Credentials bekommt, kann er diese doch dann im Prinzip gleich als Basic-Auth ( also Base64Encode(username:password) ) mitschicken, oder Du generierst anstelle von Username + Password für jeden Kunden direkt einen Api-Key, den er auch als ApiKey-Header mitschickt. Kurzer Lookup in der DB ob der API-Key drin steht (und ggf. basierend darauf die Rechte dieses Users ermitteln), und wuppdi, ist der Aufruf authorisiert.

Ob Du jetzt einen User im Token-Server deaktivierst damit er keine Tokens mehr bekommt oder den API-Key direkt invalidierst schenkt sich da meiner Meinung nach nicht wirklich viel. Und Du musst Dich nicht mit JWT's generieren, signieren und validieren herumschlagen.

Hmm.. Ja, das hat was. Ich sehe jetzt auch nicht warum der Kunde sich zuerst mit seinen Credentials ein JWT holen soll, bevor er loslegen kann. Ist der Grund ev. in sicherheitsrelevanten Gründen zu suchen? Kann so besser eine man-in-the-middle Attacke vermieden werden?
Wenn nicht, dann reicht basic-auth oder Api-Key.

[psycodad]

Zitat:

Zitat von Rollo62 (Beitrag 1494337)

Zitat:

Zitat von psycodad (Beitrag 1494327)

Ich habe das hier gefunden: https://github.com/paolo-rossi/delphi-jose-jwt . hat da jemand Erfahrung damit?

Die Library ist aktuell und wird auch in vielen Projekten verwendet.

Das bildet aber noch kein komlettes OAuth-System ab.
Aber ja, man kann sich damit was frickeln.
Ob das Sinn mach sei mal dahingestellt, ich tendiere da eher zu kompletten Lösungen die gut gepflegt sind,
statt solche Dinge selbst zu versuchen.

Naja, wenn ich eine B2C Authentifizierung machen will, dann würde ich da auch eher zu einer kompletten Lösung greifen. Ich will aber nur ein paar ausgewählten Partnern Zugriff auf die API gewähren. Ich vermute dass dann eine basic-auth oder ein API-Key aureichen würde, aber eben, ich bin mir da noch nicht sicher.

[Rollo62]

Zitat:

Zitat von psycodad (Beitrag 1494339)

Naja, wenn ich eine B2C Authentifizierung machen will, dann würde ich da auch eher zu einer kompletten Lösung greifen. Ich will aber nur ein paar ausgewählten Partnern Zugriff auf die API gewähren. Ich vermute dass dann eine basic-auth oder ein API-Key aureichen würde, aber eben, ich bin mir da noch nicht sicher.

Vielleicht ist dann die DEC Encryption Library hier auch noch interessant, von Markus.

[himitsu]

Wer ein NAS (Synology/QNAP) oder einen Himbeerkuchen hat, der kann sich auch da einen fertigen OAUTH-Server installieren.

[Phoenix]

Zitat:

Zitat von himitsu (Beitrag 1494398)

Wer ein NAS (Synology/QNAP) oder einen Himbeerkuchen hat, der kann sich auch da einen fertigen OAUTH-Server installieren.

Nur dann holt man sich blöderweise wieder das leidige Thema mit dem trusted SSL-Zertifikat für den on-premise Host sprichwörtlich ins Haus.