Omgaan met inloggegevens

Uw eerste token krijgen is nog maar het begin. Zodra een OAuth-applicatie in productie is, moeten de inloggegevens veilig worden opgeslagen, af en toe worden geroteerd en snel kunnen worden ingetrokken als er iets misgaat. Dat zijn precies de vragen die een security review stelt. Deze pagina behandelt alle drie, plus wat een gelekt token daadwerkelijk kan bereiken en wat u moet doen bij een lek.

Waar een client secret thuishoort

Bewaar het in een omgevingsvariabele of een secrets manager (AWS Secrets Manager, Vault, enz.), nooit in versiebeheer, en nooit in een configuratiebestand dat samen met uw code wordt gecommit.
Neem het nooit op in een desktopapplicatie of een browsergebaseerde client. Alles wat op de machine van een gebruiker is geïnstalleerd of aan een browser wordt geleverd, kan qua bundel worden geïnspecteerd, dus elk secret dat daarin is ingebed, moet vanaf het moment van uitgave als openbaar worden beschouwd.
Dit is precies waarom de Native Application-flow helemaal geen client secret uitgeeft: deze is bedoeld voor desktop- en CLI-integraties die geen manier hebben om er een vertrouwelijk te houden, en leunt in plaats daarvan op PKCE (een bewijs per verzoek dat gekoppeld is aan de autorisatiecode). De flow Authorization Code + aangepaste HTTPS-redirect gebruikt ook PKCE, en staat een client secret toe alleen voor vertrouwelijke clients waarvan de redirect-handler draait op een server die u zelf beheert. Een implementatie van die flow die alleen in de browser draait (SPA) moet het secret weglaten, om dezelfde reden dat de Native-flow er nooit een heeft. Zie Aan de slag: Kies een OAuth-flow.
Client Credentials is een server-naar-server-flow en vereist altijd een secret: bewaar het volgens dezelfde regels als elke andere serverzijdige inloggegeven.

Een client secret roteren zonder downtime

Het opnieuw genereren van een secret vanuit Settings → OAuth bij uw applicatie vervangt het volledig. Er is geen venster waarin het oude en het nieuwe secret allebei geldig zijn: een aanroeper die nog het oude secret gebruikt, wordt vanaf zijn eerstvolgende token- of refreshverzoek geweigerd.

Dat betekent niet dat elk lopend verzoek meteen faalt op het moment dat u roteert. Een al uitgegeven access token blijft werken tot zijn eigen TTL verloopt (ongeveer een uur, zie Levenscyclus van tokens), ongeacht wat er daarna gebeurt met het secret waarmee het oorspronkelijk is uitgegeven. Alleen een nieuwe tokenaanvraag of een refresh heeft het nieuwe secret nodig.

Aanbevolen omschakelvolgorde:

Genereer het secret opnieuw.
Werk in dezelfde wijziging elke plek bij waar uw integratie het secret opslaat (configuratie, secrets manager, elke instantie of worker), voordat een daarvan weer een token moet uitgeven of vernieuwen.
Bevestig dat nieuwe tokenaanvragen slagen met het nieuwe secret.

Als u niet alle instanties atomair kunt bijwerken, plan de rotatie dan als een gecoördineerde uitrol in plaats van een geleidelijke rollout: een instantie die nog het oude secret heeft, faalt volledig zodra ze weer een token nodig heeft, en valt niet netjes terug op het oude secret.

Toegang intrekken

Er zijn twee manieren om toegang in te trekken, en beide stoppen nieuwe toegang:

Eén autorisatie intrekken via Settings → Third-party access. De applicatie kan dan via die autorisatie geen tokens meer vernieuwen of verkrijgen, zonder gevolgen voor andere gebruikers van de applicatie.
De OAuth-applicatie verwijderen via Settings → OAuth. Daarmee wordt deze voor iedereen ingetrokken: er kunnen geen nieuwe access- of refresh tokens meer voor worden uitgegeven, en het client secret werkt niet meer, net zoals na een rotatie. Bij een applicatie die client credentials gebruikt, deactiveert dit in dezelfde handeling ook de servicegebruiker van de applicatie.

Het intrekken van een autorisatie, het verwijderen van de applicatie en het roteren van het secret laten een al uitgegeven access token ongemoeid: geen van deze acties laat het geforceerd verlopen. Beschouw dat token als bruikbaar, met zijn oorspronkelijke scopes, tot zijn eigen TTL verloopt. Zie Levenscyclus van tokens voor het volledige overzicht van wat wel en niet van invloed is op een actief token.

Wat een gelekt token kan bereiken

Een gelekt token is geen lek van uw hele organisatie: het is dubbel begrensd, in lijn met het beveiligingsmodel met drie lagen:

De OAuth-scopes (laag 1): vastgelegd in het token op het moment van uitgifte. Het later verwijderen van een scope uit de applicatie verkleint een al uitgegeven token niet; dat heeft pas effect de volgende keer dat het token wordt vernieuwd of opnieuw wordt uitgegeven.
De inhoudstoegang en rol van de servicegebruiker (lagen 2 en 3): welke nodes (organisaties, divisies, sites) de servicegebruiker van het token kan zien, en wat hij daarmee mag doen. Anders dan scopes ligt dit niet vast in het token: het wordt bij elk verzoek getoetst aan uw huidige configuratie.

De praktische conclusie: hoe strakker u de applicatie en haar servicegebruiker vooraf afbakent, hoe minder een gelekt token waard is.

Na een vermoed lek

Werk dit in deze volgorde af:

Roteer het client secret onmiddellijk (Settings → OAuth → uw applicatie). Dit is het snelste wat u kunt doen, en zorgt ervoor dat elk nieuw token- of refreshverzoek met het oude secret meteen mislukt.
Verwijder de OAuth-applicatie als u deze niet meer wilt gebruiken, of als u vermoedt dat het compromis verder gaat dan één secret. Bij een client-credentials-applicatie deactiveert dit ook de servicegebruiker, waardoor de uitgifte van nieuwe tokens volledig wordt stopgezet.
Beperk of verwijder de inhoudstoegang van de servicegebruiker. Omdat inhouds- en roltoegang (lagen 2-3) live wordt gecontroleerd in plaats van vastgelegd in het token, verkleint dit onmiddellijk wat een nog geldig gelekt token kan bereiken, zelfs voordat de TTL van dat token verloopt.
Behandel het token nog één TTL-venster lang als actief (ongeveer een uur). Geen van de bovenstaande stappen forceert het verlopen van een al uitgegeven token.
Geef nieuwe inloggegevens uit (een nieuw secret, of een nieuwe applicatie) en werk uw integratie bij voordat u het normale gebruik hervat.

Wat is de volgende stap?

Levenscyclus van tokens voor TTL’s, caching en refreshgedrag
Aan de slag: Beveiligingsmodel voor hoe scopes, inhoudstoegang en rollen samenhangen