# Onderzoek Authserver

## Vragen

### Moeten we gebruik maken van OAuth of SAML, of beide? Is het gemakkelijk om beiden te implementeren?

* Het is vrij eenvoudig om zowel OAuth als SAML te implementeren
* Om OAuth te kunnen gebruiken voor authentication (als SSO) zullen we gebruik moeten maken van OpenID Connect. Vuistregel: OAuth is voor _authorization_, OpenID Connect is voor _authentication_.
* Voor 1.0 zullen we kijken of het binnen het timeframe mogelijk is om zowel SAML als OAuth2.0 te implementeren, waarbij we met OAuth (+OIDC) beginnen en SAML een nice-to-have is

### Hoe we het beste het kunnen koppelen met de bytecore en externe applicaties

Waarschijnlijk is de beste oplossing om het authenticatie en authorizatie stuk los te hebben van de rest

### Hoe we permissielevels(/-groepen) moeten inrichten

LDAP, bijvoorbeeld met OpenLDAP. Maar dit is niet iets wat er bij MVP in hoeft te zitten.

### Hoe/waar gebruikers moeten inloggen

Op een los domain wat vanwege veiligheidsoverwegingen geen enkele andere functie heeft dan het inloggen en sessiebeheer van Bytecode Auth. Bijvoorbeeld auth.bytecode.nl.

### Moeten we de auth integreren in de bytecore, of als losse applicatie draaien (bv. onder auth.bytecode.nl), ik neig naar dat laatste en dan via gRPC authenticaten, maar hierbij ook weer, dan moeten we dus dubbel permissies etc. gaan bijhouden?

Losse applicatie is het eerste voorstel. Andere mogelijkheid is dat we het wel als inbouwen in de Bytecode Gateway, maar dan als losse service, waardoor het later gemakkelijk als losstaande server kunnen draaien.

### Wat is er nog nodig om ook andere (3rd party) applicaties te koppelen, zodat we bv. bij Slack of zo kunnen inloggen via Bytecode Auth

Het toe kunnen voegen van clients (via ID en Secrets voor OAuth, SAML nog te onderzoeken).

We moeten ook een lijst hebben van services die zijn toegestaan. Dit kan in de MVP als een variable bestand ingeladen worden.

### Hoe moeten we dingen zoals de client ids en secrets gaan opslaan?

Dit kan in de database. Het is belangrijk dat dit altijd alleen maar server side (back channel) wordt geregeld en niet via een browser (front channel) verloopt.

### Is het mogelijk om de auth server in de bytecore te draaien en dan onder een los domain een React frontend voor inloggen etc. te draaien, werkt alles met oauth2 dan nog voor 3rd party applicaties, en is dit de beste keuze als dit kan?

Dit is sowieso mogelijk door gebruik van NextJS, maar voor een kleine applicatie is het scheiden van de back- en front-end veel werk en zal er veel tijd nodig zijn voor het garanderen van de security. Het is hierom (voor versie 1.0) het gemakkelijkste om alles server side te verwerken. Ook terugkomend op dat OAuth communicatie voor een deel niet via de browser mag verlopen is het handiger om alles server-side te houden.

### Hoe past JWT binnen OAuth/OpenID Connect/SAML? Is het goed om JWTs binnen deze flow te gebruiken?

SAML is allemaal XML en daarbij hebben we niets te maken met JWTs. Bij OpenID Connect wordt er gebruik gemakt van een JWT om daar informatie van de gebruiker mee te geven.

### Gaan we voor OAuth werken met reference tokens, of met value (self-encoded) tokens

Waarschijnlijk met value tokens. Onderbouwing nodig.

---

## Implementatie

* De applicatie wordt gebouwd in Golang (?), met templating etc. aan de serverkant en PostgreSQL als achterliggende database
* Er komt een losse applicatie te draaien op auth.bytecode.nl en dit wordt niet geintegreerd in de Bytecore applicatie direct
* Bij een ingelogde gebruiker is te zien als wie de persoon is ingelogd
* Indien een gebruiker niet is ingelogd wordt een loginscherm getoond
* Sessies voor auth.bytecode.nl worden via cookies beheerd
* We bouwen zelf gebruikersbeheer, inlogmechanisme etc. in
* Voor SAML wordt auth.bytecode.nl/saml/* gebruikt
* Voor OAuth (en OIDC) wordt auth.bytecode.nl/oauth/* gebruikt
* Voor JWT wordt auth.bytecode.nl/jwt/* gebruikt
* Via een CLI kunnen gebruikers en clients (client applicaties) worden toegevoegd
* Voor de veiligheid worden alle security headers geconfigureerd dat alleen content van auth.bytecode.nl geladen mag worden
* De Bytecore kan via auth.bytecode.nl/grpc/* authenticatie en authorisatie verifieren (niet in versie 1.0)

---

## Roadmap

### MVP
* De eerste stap is een CR(UD) applicatie (Go, Postgres/SQLx, Bcrypt) waarin username/password combinaties kunnen worden gecheckt of deze gegevens kloppen. Gebruikers toevoegen kan via CLI
* De volgende stap is het mogelijk maken om gebruikers te verwijderen of wachtwoorden aan te passen (met een CLI)
* De volgende stap is het toevoegen van OAuth2 support, clientside en serverside
* Zodra bovenstaande geimplementeerd is, is de MVP klaar voor gebruik

### MMP
* Toevoegen van JWT support
* Bij doorontiwkkeling is SAML ondersteuning een mogelijkheid
* Een access log in de database is een volgende stap
* Key invalidation voor JWT is een volgende stap
* Het kunnen aanpassen van eigen gebruiksgegevens (wachtwoord etc.) is de volgende stap
* Gebruikersrollen en/of support voor permissies globaal is de volgende stap (waaronder klantenrol)
* Een admin user role die gebruikers kan aanpassen is de laatste stap voor MMP
* Gebruikersrollen en/of support voor permissies per toegestane service is een stap later

---

## Voorstel Julian voor developmentaanpak

SAML wordt op dit moment uitgefaseerd door OpenID. OpenID staat ook toe dat een applicatie toegang heeft tot een users resources namens die user. Wat betere cooperatie toestaat. OpenID is een protocol dat gebouwd is op oauth. Het gebruikt oauth als authorizatie protocol en dan OpenID als authenticatie van een persoon. Dit zorgt ervoor dat OpenID goed te gebruiken is voor verschillende applicaties binnen dezelfde sessie. Een applicatie moet wel op IP basis toegang krijgen om gebruik te maken van de OpenID provider. Op die manier zorg je ervoor dat er geen bad actors zomaar gebruik gaan maken van een users OpenID token.
Mijn voorstel was om gebruik te maken van hydra https://github.com/ory/hydra . Hydra is een OpenID certified OpenID connect en OAuth 2.0 provider. Dit betekent dat de interne verificatie en authorizatie officieel geverifierd is waardoor er minder ruimte is voor fouten. De code voorziet alleen niet van een sign up en consent pagina. Deze kunnen we dan zelf maken en toevoegen wat ons alle mogelijke customisation kan laten doen.

---

## Bronnen

### General

* https://www.purchasecontrol.com/uk/blog/saml-vs-oauth-vs-openid/
* https://stormpath.com/blog/oauth-is-not-sso
* https://stackoverflow.com/questions/7699200/what-is-the-difference-between-openid-and-saml
* https://en.wikipedia.org/wiki/OpenLDAP

### Video

* https://www.youtube.com/watch?v=996OiexHze0
* https://www.youtube.com/watch?v=t18YB3xDfXI
* https://www.youtube.com/watch?v=PfvSD6MmEmQ

### Libraries (evt. met voorbeeldcode)

* https://github.com/golang/oauth2
* https://github.com/go-oauth2/oauth2
* https://github.com/vgarvardt/go-oauth2-pg
* https://www.sohamkamani.com/golang/2018-06-24-oauth-with-golang/
* https://github.com/russellhaering/gosaml2

### Voorbeeldprojecten

* https://github.com/WISVCH/connect
* https://github.com/RichardKnop/go-oauth2-server
* https://github.com/crewjam/saml
* https://github.com/amdonov/lite-idp

### Security

* https://security.stackexchange.com/questions/93902/is-postgress-uuid-generate-v4-securely-random#:~:text=1%20Answer&text=The%20PostgreSQL%20documentation%20says%20that%20UUID%20generation%20relies%20on%20the%20OSSP%20library.&text=Therefore%2C%20caution%20advises%20not%20to,but%20not%20hiding%20access%20errors
* https://www.softwaresecured.com/federated-identities-openid-vs-saml-vs-oauth/