Autorisatie is de stap die bepaalt wat een al geidentificeerde gebruiker mag doen: welke knoppen hij kan indrukken, welke paginas hij kan openen, welke records hij mag wijzigen. Het draait direct nadat de identiteit is bevestigd, en hier zit in de praktijk het grootste deel van je beveiligingsbeleid.
Een hotel maakt het onderscheid duidelijk. Inchecken bewijst wie je bent, dat is authenticatie. De keycard die je krijgt is autorisatie: hij opent je kamer en de fitnessruimte, maar niet het personeelskantoor of de deur van iemand anders. Dezelfde gast, andere deuren, allemaal bepaald door wat je kaart mag. In software is de ‘kaart’ een set rechten die aan je account hangt.
De meeste systemen bundelen die rechten in rollen zodat het beheersbaar blijft, een patroon dat RBAC heet. Als je het fijner nodig hebt, iemand beperken tot alleen zijn eigen klanten of regio, dwingt row-level security dat diep in de database af. Autorisatie is ook de kern van hoe toegangscontrole in de praktijk werkt.
De klassieke fout is rechten alleen in de interface controleren. Verberg je de ‘verwijderen’-knop maar bewaak je het onderliggende verzoek niet, dan kan een nieuwsgierige gebruiker dat verzoek alsnog rechtstreeks aanroepen en is het record weg. De regel moet dus op de server worden afgedwongen, bij elk verzoek, niet alleen verstopt in het scherm. Als de ene app namens jou iets doet in een andere, zoals een tool die in je agenda post, regelt OAuth die gedelegeerde toestemming zonder ooit je wachtwoord te delen.
Bij TopDevs brengen we de autorisatieregels in kaart voordat we de eerste functie schrijven, zodat elke gebruiker precies bereikt wat hij moet bereiken en overal elders tegen een nette ‘niet toegestaan’ aanloopt.
