Authenticatie zelf doen of tool gebruiken

[ione]

Ik ben bezig om een webapplicatie voor een klant te ontwikkelen. Backend wordt Java Spring Boot 3. Frontend React. En database MySQL.

Ik ga de boel bij DigitalOcean draaien.
Deze applicatie gaat al vrij snel voor twee klanten draaien waarbij ik de software wel gescheiden wil houden, omdat het weleens zou uitgroeien naar maatwerk per klant.

Het idee dat ik nu heb is een droplet(pod) per klant te doen waar de applicatie (front- en backend) draait. Een Droplet waar een DB-server draait daarin de database per klant.

Maar waar ik nu een beetje tegenaan loop is de
authenticatie. Dit kan ik zelf doen door met JWT-token te werken mbv Spring Security. Maar ik zou ook een aparte droplet kunnen draaien met daarin bijvoorbeeld een instantie van KeyCloak die dit dan voor mij regelt.
Is het inzetten van KeyCloak overkill voor mijn setup? Of is het juist wel aan te raden in plaats van zelf ontwikkelen?
Als ik de info er beetje lees neig ik naar dat het overkill is, maar aan de andere kant als het al helemaal goed in zo’n tool zit waarom zou ik dan opnieuw het wiel gaan uitvinden.
Heeft iemand hier ervaring mee? Of kan mij wat adviseren?

[The Eagle]

Als ik een klant bij jou ben en je applicatie gebruik is iets als single sign on en integratie met een eigen Azure ad wel een vereiste.

Dus tenzij je dat zelf kunt bouwen en makkelijk onderhouden, zou ik er een framework op zetten die dat voor je doet

[The Realone]

Vooropgesteld, ik ben geen developer dus ik heb slechts zeer beperkte kennis van hoe zij werken. Maar toevallig liepen wij tegen hetzelfde vraagstuk aan, echter wel nadat we een eigen auth service hadden geschreven.
Ondertussen was ik bezig een eigen instance van DexIdp te draaien voor auth op onze k8s infra en kwam dus ook de vraag waarom we dit niet zouden gebruiken.

De conclusie was; Als we het nu allemaal opnieuw zouden doen, zouden we Dex (of KeyCloak) gebruiken. De redenen daarvoor waren:

• Een betere compatibiliteit met andere systemen, nu worden de ontwikkelde applicaties enkel nog intern gebruikt, maar het doel is om die ook bij andere organisaties aan de man te brengen. Dex biedt out-of-the-box connectors voor een boel IP's terwijl onze auth service enkel Google Auth doet.
• Transparanter en wellicht wat vertrouwder voor die eventuele 3e partijen. Dex is, net als Keycloak, een bekende naam met brede ondersteuning.
• Een werklast en verantwoordelijkheid minder voor onze ontwikkelaars voor het aanpassen en bijhouden van de auth service. Het is ook eenvoudiger om te kunnen eisen dat zij zich ergens aan moeten conformeren wanneer je een tool als Dex gebruikt, dan wanneer het je eigen maatwerk is.

Dat gezegd hebbende is het erg afhankelijk van hoe je je applicatie in zet en hoe je denkt dat dit in de toekomst ontwikkeld. Als wij niet als uitgangspunt hadden genomen dat we de applicatie bij derden aan willen bieden, was het aan ander verhaal geweest.

[ Voor 9% gewijzigd door The Realone op 06-11-2023 21:40 ]

[Kriekel]

Ik ben begonnen met het zelf schrijven van authenticatie, dat was destijds de enige manier. Het grote nadeel aan zelf authenticatie schrijven is dat jij verantwoordelijk bent dat de wachtwoorden veilig worden encrypted en opgeslagen. Daarnaast zit je met het onthouden van login sessies. Wil je dat bewaren zit je al snel aan cookies. Die kunnen worden gestolen en of gemanipuleerd.

Nu laat ik dat afhandelen door identiy providers, bijvoorkeur azure, maar KeyCloak schijnt ook prima te zijn (blijf alleen weg van WSO2). Hiermee zijn die applicaties verantwoordelijk voor het wachtwoord management en hoef jij de login alleen maar in de browser sessie te bewaren, komt de gebruiker met een nieuwe sessie stuur je hem gewoon even naar de IP voor een nieuwe sessie.

Voor organisaties brengt dit als extra voordeel dat ze oude gebruikers maar op 1 plek hoeven te verwijderen/deactiveren en ze kunnen nergens meer bij.

IP's zijn wel extra gedoe met hosting (als je het zelf doet), maar dat is het wat mij betreft waard. (Dat heb ik overigens nog nooit zelf opgezet)

[ione]

Bedankt voor de reacties. Hier kan ik wel wat mee. Ik ga wat verder naar KeyCloak kijken en hier even eea mee proberen.

[Gerco]

Authenticatie is een vak apart en wil je als applicatie ontwikkelaar liever niet aan beginnen, je hebt al genoeg te doen. Als je applicatie/API OAuth2 ondersteund dan kun je bijna alle kanten uit. Heeft je klant een account bij Ping/Okta: prima, hebben ze dat niet dan kun je Keycloak voor ze opstarten. Zodra je code begint te schrijven voor wachtwoord encryptie ga je de verkeerde kant op.

Dingen als Ping/Okta bieden ook meteen integratie aan met eventueel bestaande Azure AD (tegenwoordig Entra), Google Workspace en soortgelijke dingen (kan ook direct als je wilt, MS en Google ondersteunen ook OAuth2). Ook het afhandelen van dingen als password resets, verificatie emails en 2 factor authenticatie is iets wat je liever wilt uitbesteden als applicatie ontwikkelaar en zeker als het om support gaat. Laat de klant dat lekker zelf doen op hun Ping/Okta portals zodat jij je er niet mee bezig hoeft te houden.

Lang verhaal kort: Bouw je applicatie op OAuth2 en laat de rest door iemand anders afhandelen.

[ Voor 3% gewijzigd door Gerco op 08-11-2023 15:10 ]

[ione]

In dit geval gaat om een kleinschalig project voor twee kleine bedrijfjes, maar wil het wel goed opzetten.
Het zal een applicatie zijn die door twee klanten gebruikt gaat worden (Max 5 gebruikers per klant). Zou je dan per klant een KeyCloak instantie opzetten of één instantie en daarin een scheiding per klant?
Het plan was om de boel bij DigitalOcean te hosten en dan zou ik twee pods (voor elke klant één) hebben met de applicaties daarin. Een pod voor de database-server en één pod voor KeyCloak.

[Douweegbertje]

ione schreef op vrijdag 10 november 2023 @ 08:27:
In dit geval gaat om een kleinschalig project voor twee kleine bedrijfjes, maar wil het wel goed opzetten.
Het zal een applicatie zijn die door twee klanten gebruikt gaat worden (Max 5 gebruikers per klant). Zou je dan per klant een KeyCloak instantie opzetten of één instantie en daarin een scheiding per klant?
Het plan was om de boel bij DigitalOcean te hosten en dan zou ik twee pods (voor elke klant één) hebben met de applicaties daarin. Een pod voor de database-server en één pod voor KeyCloak.

Segmentatie is je vriend. Voor allerlei redenen.

[Davidshadow13]

ione schreef op vrijdag 10 november 2023 @ 08:27:
In dit geval gaat om een kleinschalig project voor twee kleine bedrijfjes, maar wil het wel goed opzetten.
Het zal een applicatie zijn die door twee klanten gebruikt gaat worden (Max 5 gebruikers per klant). Zou je dan per klant een KeyCloak instantie opzetten of één instantie en daarin een scheiding per klant?
Het plan was om de boel bij DigitalOcean te hosten en dan zou ik twee pods (voor elke klant één) hebben met de applicaties daarin. Een pod voor de database-server en één pod voor KeyCloak.

Je kunt prima één Keycloak server draaien. Je kunt daarin gewoon meerdere Realms maken voor de verschillende klanten en per realm ook meerdere authenticatie clients, bijvoorbeeld als je later nog meerdere applicaties per klant wil gaan draaien. Ik zou niet meerdere KeyCloak instanties naast elkaar draaien dat is niet nodig en zorgt alleen maar voor onnoddige extra configuratie.