6. JSON Web Tokens

De startbestanden van de oefening zijn gebaseerd op het eindresultaat van Les 3, maar met enkele extra's.

Startbestanden

Wat is er toegevoegd aan de startbestanden

De collectie 'users': deze bevat users met hun mogelijk role. Een rol kan 'guest', 'admin' of 'contributor' zijn. Er zijn al 3 users klaargezet, hun paswoorden zijn telkens de username van het e-mail adres ("admin", "guest" en "contributor"). Eens je de voorbereiding klaar hebt kan je deze bekijken via MongoDB Compass. Ook het schema hiervoor is reeds voorzien. Er is reeds een route voorzien voor de accounts (deze moet nog afgewerkt worden). De password utils zijn ook reeds voorzien.

Voorbereiding

• Zet de docker container op.
• Open MongoDB Compass en importeer zowel de series collection als de users collection uit de startbestanden.

Beveiliging via JWT

• Zorg ervoor dat de gebruiker kan inloggen m.b.v. JSON Web Tokens, deze keer zonder sessions in de databank.
• Zorg voor enkele beveiligde routes. De admind mag altijd alles, de contributor mag alles wat een guest moet kunnen.

Volgende routes/methodes moeten beschikbaar zijn zonder beveiliging:

• Inloggen (deze route moet je nog nieuw aanmaken)
• Aanmaken van een account (deze route is reeds voorzien)

Volgende routes/methodes mogen enkel beschikbaar zijn voor een ingelogde gebruiken (eender welke rol):

• Uitloggen (deze route moet je nog nieuw aanmaken)
• Refresh token aanvragen (deze route moet je nog nieuw aanmaken)

Volgende routes/methodes mogen enkel beschikbaar zijn voor een ingelogde guest:

• Series bekijken/zoeken (deze routes zijn reeds voorzien -> vergeet de getById niet)

Volgende routes/methodes mogen enkel beschikbaar zijn voor een ingelogde contributor:

• Series toevoegen (deze route is reeds voorzien)
• Series aanpassen (deze route is reeds voorzien)

Volgende routes/methodes mogen enkel beschikbaar zijn voor een ingelogde admin:

• Series verwijderen (deze route is reeds voorzien)

Gebruik de userId als payload voor de token, we hebben nu geen sessies in de databank.

Beveiliging via APIKey

Een veelgebruikte methode om een API te beveiligen is via een APIKey. Deze key kan de gebruiker aanvragen, gewoonlijk via een web omgeving, en deze wordt voor een lange periode toegekend. De APIKey dient bij elke request meegegeven te worden in de header. We gaan hier een random string voor genereren, maar uiteraard is het ook mogelijk om via encryptie informatie in de key te verstoppen (zoals de rol). Een APIKey wordt vooral gebruikt wanneer het niet wenselijk is dat een gebruiker regelmatig moet inloggen (wanneer de requests van de client uitgevoerd worden door een background app op een server bijvoorbeeld).

Je kan de APIKey uitlezen via:

req.headers["x-api-key"] as string

In Postman kan je in de request een extra header toevoegen met de naam "x-api-key".

In de index.ts is een 'test' methode voorzien waar de APIKey uitgelezen wordt, deze kan je gebruiken als voorbeeld.

• Maak een veld bij aan in de user tabel om een APIKey bij te houden:
  • Voeg dit veld toe in de interface en het schema, je hoeft in de DB zelf niets te doen
• Maak een route bij waarin een ingelogde admin een APIKey kan aanvragen voor een bepaalde gebruiker (via een userId in de URL parameters). Deze genereert een random string via de randomBytes methode, update het veld in de databank, en geeft de APIKey terug. We veronderstellen hier dat de admin de APIKey aan de user bezorgt buiten onze app.
• Zorg ervoor dat een gebruiker die een (correcte) APIKey meegeeft niet hoeft in te loggen:
  • Pas het sessionManagement aan. Indien de APIKey is meegegeven haal je de user op met die key en stop je zijn rol bij in de request (hiervoor moet je ook de request uitbreiden).
  • Pas je middleware voor de verschillende rollen aan zodat deze ook de nieuwe rol gebruikt.

Het moet dus zowel werken als de gebruiker is ingelogd via een bearer token, of als de gebruiker een correcte APIKey meegeeft.

Oplossing

Uitgewerkte oplossingen