Bronnen · 43
OAuth en OpenID Connect: een end-to-end integratie verifiëren
Scheid aanmelding, delegatie en gegevensrechten, en test vervolgens omleidingen, tokens, sessies en intrekking.
Bijgewerkt · 3 min
Wat deze handleiding helpt bereiken
- Scheid identiteit van autorisatie
- Onbedoelde omleidingen en tokens afwijzen
- Weigeringen net zo zorgvuldig testen als successen
- Toegangsverwijdering na vertrek of incident verifiëren
Snelle controle
- Welke provider en uitgever worden verwacht?
- Is de omleidings-URI correct geregistreerd?
- Wordt een ID-token ten onrechte gebruikt als toegangstoken?
- Controleert elke resource het eigenaarschap?
- Welke toegang blijft behouden na intrekking?
Stapsgewijze methode
- 1
Teken het geïmplementeerde stroomschema
Identificeer de openbare of vertrouwelijke client, browser, autorisatieserver, API en OIDC-provider. Leg vast waar codes en tokens naartoe gaan, wie ze opslaat en welke rollen worden toegekend. Een verkoopdiagram geeft niet de daadwerkelijke implementatie weer.
Resultaat: flow, vertrouwensgrenzen en componenteigenaren.
- 2
Controleer de aanmeldingstransactie
Gebruik de codeflow met PKCE die geschikt is voor de client. Controleer S256, transactiebinding, geregistreerde redirects en bescherming tegen vervalste verzoeken. Test een onverwachte URI, onjuiste verificator, herhaalde code en onverwachte uitgever. RFC 9700 scheidt vereisten en aanbevelingen per clienttype.
Resultaat: toegestane en geweigerde testresultaten.
- 3
Valideer het juiste token
De API valideert zijn toegangstoken volgens de formaat- en providerregels: handtekening of introspectie, uitgever, doelgroep, vervaldatum en machtigingen. De OIDC-client valideert afzonderlijk het identiteitstoken. Een geldige handtekening bewijst niet dat het token bij deze API hoort.
Resultaat: validatiecontract en tests voor doelgroep en vervaldatum.
- 4
Controleer bedrijfsrechten
Test een object dat eigendom is van een ander account, een lagere rol, een privéveld en een administratieve bewerking. Een scope of geauthenticeerde gateway vervangt geen servercontroles op de aangevraagde resource. Gebruik geautoriseerde testaccounts en -gegevens.
Resultaat: rol-, object-, bewerking- en verwachte-weigeringmatrix.
- 5
Test vervaldatum en intrekking
Scheid lokale sessie, providersessie, toegangstoken en vernieuwingstoken. Test vertrek, verloren apparaat, rolwijziging, rotatie van ondertekeningssleutel en provideruitval. Documenteer de resterende toegangstijd in plaats van aan te nemen dat uitloggen onmiddellijk alles intrekt.
Resultaat: tijdlijn voor het intrekken van toegang en uitzonderingen.
- 6
Observeer zonder geheimen bloot te leggen
Registreer transactiereferentie, validatiebeslissing, foutcategorie en configuratieversie. Sluit codes, tokens en geheimen uit. Bereid diagnose, integratie-uitschakeling en terugdraaien naar een gevalideerde configuratie voor; herhaal tests na providerwijzigingen.
Resultaat: werkprocedure en regressietests.
Fictief uitgewerkt voorbeeld
Illustratieve situatie
Illustratieve situatie: twee clients gebruiken één identiteitsprovider. Een token dat geldig is voor de eerste client wordt aangeboden aan de API van de tweede client.
Beslissing en verwachte bewijs
De API wijst de verkeerde doelgroep af, registreert een token-vrije trace en retourneert geen gegevens. De weigering wordt een regressietest.
Onderscheid de mechanismen
| Mechanisme | Doel | Verificatie of beperking |
|---|---|---|
| OAuth 2.0 | Toegang tot resources delegeren | Server-side objectmachtigingen |
| OpenID Connect | Identiteit vaststellen via een gevalideerd ID-token | Validatie van uitgever, doelgroep en transactie |
| Applicatiesessie | Applicatieaanmelding beheren | Vervaldatum, ongeldigverklaring en sessiebeveiliging |
Managementindicatoren
| Indicator | Wat het meet | Eerste actie |
|---|---|---|
| Weigeringen corrigeren | Verboden gevallen daadwerkelijk geblokkeerd | Alle onverwachte acceptaties corrigeren |
| Vertraging bij intrekking | Tijd tot relevante toegang verdwijnt | Sessies en tokens afzonderlijk controleren |
| Validatiefouten | Afwijzingen op basis van oorzaak en versie | Aanvallen scheiden van configuratiefouten |
Veelvoorkomende fouten
- Authenticatie verwarren met autorisatie
- Elke doelgroep accepteren na controle van de handtekening
- Brede redirect-URI's registreren
- Tokens loggen Voor eenvoudiger debuggen
Veelgestelde vragen
Vervangt PKCE alle controles?
Nee. Het beschermt de code-uitwisseling in de beoogde flow; tokenvalidatie, redirects, zakelijke autorisatie en sessies moeten nog steeds worden gecontroleerd.
Is een JWT een machtiging?
JWT is een formaat. Claims worden pas bruikbaar na validatie en toepassing van uw API-regels.
Moet validatie helemaal opnieuw worden opgebouwd?
Geef de voorkeur aan een onderhouden bibliotheek en documentatie van de provider, en test vervolgens uw configuratie. Een correcte bibliotheek kan nog steeds verkeerd geconfigureerd zijn.
Officiële referenties
Referenties ondersteunen de methode. Pas controles aan uw context aan; ze zijn geen certificering. Originele referentietitels en brondocumenten kunnen in een andere taal zijn.
