API-foutopsporingstools: de zes tabbladen die ik open als een eindpunt tegen mij liegt

Een eindpunt voor licentieactivering op een van mijn Laravel-projecten begon elk token dat het werd overhandigd af te wijzen. Niet een paar tokens. Elk token, inclusief degenen die dezelfde server negentig seconden eerder had uitgegeven. de logboeken zeiden token expired. De tokens waren niet verlopen. Ik heb het grootste deel van een zaterdag ervan overtuigd dat de klok op de doos was afgedwaald.

Het had niet. De bug was een regel:

if (payload.exp < Date.now()) throw new Error('token expired')

exp In een JWT is tweede soort sinds het tijdperk is RFC 7519 §4.1.4 daar ondubbelzinnig over. Date.now() In JavaScript-retouren milliseconden. Dus ik vergeleek een tiencijferig getal met een getal van dertien cijfers, en tiencijferige getallen zijn altijd kleiner. Elk token in het universum was voor altijd verlopen. De oplossing was Date.now() / 1000. De diagnose duurde acht uur omdat ik eigenlijk nooit zag op het token bleef ik mijn eigen code herlezen, wat het foutopsporingsequivalent is van het zoeken naar je bril terwijl je hem draagt.

Wat uiteindelijk de lus brak, was het plakken van het token in een decoder, lezend exp: 1748952000, om dat om te zetten naar een date en een tijdstempel te zien die twee weken in de toekomst is. Het token was prima. Mijn vergelijking was verkeerd. Dertig seconden kijken naar Data Beat acht uur kijken naar code.

Dat' s waar deze gids over gaat Niet slimme foutopsporingsfilosofie - de specifieke, saaie, niet-glamoureuze browsertools die ik bewaar in een tabgroep genaamd & quot; API Debug, & quot; waar elk van hen eigenlijk voor is, en de faalmodi die ze vangen Alles hier draait client-side op Toolz.dev, wat belangrijker is dan het klinkt zoals het doet wanneer het ding dat je op het punt staat te plakken een token voor de productiebearer is.

tl;dr: Wanneer een API zich misdraagt, stop dan met het lezen van uw code en begin met het lezen van de payload. Formatteer de reactie met de JSON-formatter. breek het token met de JWT-decoder, geen generieke Base64-tool. draaien exp, iat, en X-RateLimit-Reset in echte dates met de tijdstempel converter. vergelijk een werkende reactie met een kapotte met de tekst diff Of beter, de JSON-differentiatie. decodeer query-string mangling met de URL-encoder. Het draait allemaal in uw browser - het token gaat nooit over de draad.

Waarom voelt het debuggen van een API zoveel erger dan het debuggen van code?

Want je kunt er niet doorheen stappen. Een lokale bug heeft een stacktracering, een debugger en een breekpunt. Een API-bug heeft een string. De server van iemand anders heeft die string geproduceerd, volgens de regels die je maar half kent, en het is jouw taak om er achteruit te werken.

Dat doet de gebruikelijke vaardigheid om. Het knelpunt is geen logica, het is leesbaarheid. Bijna elke API-bug die ik de afgelopen jaren heb achtervolgd, was onzichtbaar totdat ik de gegevens leesbaar maakte:

• een verkleinde JSON-reactie van 4.000 tekens die bleek te hebben "data": null begraven op diepte zes.
• Een Base64-payload die decodeerde naar een foutbericht dat de API de API had gedecodeerd, was te beleefd om de statuscode in te voeren.
• Een webhook die mislukte handtekeningverificatie omdat de body een achterblijvende nieuwe regel had die mijn HTTP-client behulpzaam was.
• Een tijdstempel die in milliseconden was toen de docs seconden zeiden. (tweemaal. verschillende bedrijven.)

Geen van deze waren moeilijke problemen. Ze waren allemaal onleesbaar Problemen. De onderstaande tools bestaan ​​om de gegevens snel genoeg leesbaar te maken dat u merkt dat uw ogen anders voorbij zouden glijden.

Welk hulpmiddel voor welk symptoom?

Dit is de tafel waarvan ik wou dat iemand me vijf jaar geleden had gegeven. Symptoom aan de linkerkant, eerst naar rechts bewegen.

Alles hieronder is de lange versie van die tafel.

Hoe maak ik een API-antwoord in tien seconden leesbaar?

Plak het in de JSON-formatter. Dat' is de hele techniek, en I' Ik ben niet vlot - de enige foutopsporingsgewoonte met de hoogste hefboomwerking die ik heb, is weigeren redeneren Een payload die ik niet heb geformatteerd.

Hier is een antwoordvorm die ik krijg van een factureringsprovider, precies zoals het van de draad komt:

{"subscriptions":[{"id":"sub_7f3d8a2b","status":"active","plan":{"id":"pro_annual","interval":"year","amount":9900},"current_period_end":1748952000,"cancel_at_period_end":false}],"has_more":false}

Geformatteerd, it' is een geheel ander object - niet voor de parser, maar voor mij:

{
  "subscriptions": [
    {
      "id": "sub_7f3d8a2b",
      "status": "active",
      "plan": {
        "id": "pro_annual",
        "interval": "year",
        "amount": 9900
      },
      "current_period_end": 1748952000,
      "cancel_at_period_end": false
    }
  ],
  "has_more": false
}

Nu zie ik dat amount is 9900 en niet 99.00- it's in centen, wat de meest voorkomende integratiebug in betalingen is - en dat current_period_end is een tiencijferig geheel getal, wat seconden betekent, wat betekent dat je het niet overhandigt aan new Date() direct.

Validatie vangt wat je ogen niet doen

Formatteren ook valideert. Een parsfout is informatie. De fouten die daadwerkelijk in echte payloads verschijnen:

• sleep komma's. Legaal in JavaScript, illegaal in JSON (per RFC 8259). Handbewerkte armaturen zitten er vol mee.
• enkele aanhalingstekens. JSON vereist dubbele aanhalingstekens. str(dict) Uitvoer is geen JSON, hoezeer het ook lijkt.
• Niet geciteerde sleutels. Hetzelfde verhaal - dat' is een JavaScript-object letterlijk, niet JSON.
• NaN / Infinity. Sommige serializers zenden ze uit. JSON heeft dergelijke letterlijke waarden niet.
• een bom. een UTF-8 byte-ordermarkering voor { Zal een strikte parser een document laten afwijzen dat er perfect uitziet op het scherm.

Als uw JSON geldig is, maar de maken is fout, dat' is een ander hulpmiddel - zie het diff-gedeelte hieronder.

Waarom een JWT-decoder gebruiken in plaats van alleen het token te decoderen?

U kunt een JWT met de hand decoderen. Ik heb het jaren gedaan. Het is een slechte gewoonte, en hier is waarom.

Een JWT (RFC 7519) is drie brokken gescheiden door stippen: header, payload, handtekening. Elke brokken is base64url, niet standaard Base64 - RFC 4648 §5, het URL-veilige alfabet dat swapt +→- en /→_ en laat meestal vallen = opvulling. Voer dat naar een strikte standaardbasis64-decoder en het zal u ofwel in stilte rommelen. Dus de handmethode betekent dat je op stippen splitst, opnieuw wordt geplakt en het alfabet verwisselt, elke keer weer, en dan naar rauwe JSON.

de JWT-decoder doet dat allemaal in één plak en - het deel dat daadwerkelijk tijd bespaart - presenteert de claims als claims Degene die ik check, om

• exp (vervaldatum) en iat (uitgegeven op) - beide gecijferdheid, d.w.z. tweede soort Sinds 1970-01-01 UTC. Dit is het veld dat mijn zaterdag at.
• aud (publiek) - een token dat is geslagen voor uw enscenerings-API zal structureel perfect zijn en nog steeds worden afgewezen door prod.
• iss (uitgever) - na een migratie van identiteitsverstrekkers is dit het veld dat stilletjes veranderde.
• alg in de header - als er staat none, je hebt een beveiligingsprobleem, geen foutopsporingsprobleem.

Neem het canonieke voorbeeld token dat iedereen gezien heeft:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Koptekst: {"alg":"HS256","typ":"JWT"}. laadvermogen: {"sub":"1234567890","name":"John Doe","iat":1516239022}. en iat er is 2018-01-18T01:30:22Z- wat je alleen weet door het door een tijdstempelconverter te laten lopen, wat het hele punt van de volgende sectie is.

Het ding dat een decoder niet doet

Decodering is niet aan het verifiëren. Iedereen kan een JWT decoderen; de payload is gecodeerd, niet versleuteld. Een decoder vertelt je wat het token vordering, nooit of de claim waar is. Handtekeningverificatie vindt plaats op uw server met uw geheim, en geen enkele browsertool zou dat geheim ooit moeten krijgen. Behandel een gedecodeerde JWT zoals je een inzending van een formulier behandelt: als een bewering van een vreemde.

Hoe voorkom ik dat ik tijdstempels verkeerd krijg?

Leer de cijfers tellen te lezen. Dit is de goedkoopste debugging-vaardigheid in het hele veld en het duurt een minuut om te leren.

Tien cijfers betekent seconden. Dertien betekent milliseconden. JavaScript's Date Constructor wil milliseconden; UNIX, Python's time.time(), go's Unix(), php's time(), en de meeste API's' exp Velden spreken seconden. Alles stroomafwaarts van die mismatch is chaos.

En de chaos is luid in de ene richting en stil in de andere. gebruiken tweede soort naar een milliseconde parser en je krijgt 1970 - een bug die zo duidelijk is dat je hem in een minuut oplost Feed milliseconden naar een tweede soort parser en je krijgt het jaar 56122. ik controleerde: 1708876200000, geïnterpreteerd als seconden, landt op 17 februari in het jaar 56122. Dat' is de richting die stilletjes wordt verzonden, omdat niets gooit - een abonnement vervalt eenvoudigweg nooit en niemand merkt het een kwart.

de tijdstempel converter Bestaat zodat je dit in één pasta kunt regelen in plaats van er ruzie over te maken. plaksel 1748952000, lees de datum, ga verder. Plak de X-RateLimit-Reset Header Je API klaagt over en ontdekt dat je vier minuten hebt om te wachten, niet vier uur. Als de tijdstempel naïef is (geen Z, geen offset) en je moet redeneren over wat het betekent in een andere regio, de tijdzone-omzetter is de opvolging.

Nog twee keerstempelvallen die het waard zijn om te weten

Het probleem van 2038 is echt en gedateerd. Een ondertekende 32-bits seconden teller loopt over 2147483647, dat is 2038-01-19T03:14:07Z. Elk systeem dat nog steeds tijd opslaat in een ondertekende 32-bits int - en er zijn er meer in ingebedde en oudere databasekolommen dan iemand wil toegeven - breekt dan. Als u & # 39; vandaag langlevende vervaldatums instelt, kunt u hier al op reageren.

Naïeve tijdstempels zijn een leugen door omissie. 2026-02-25T14:30:00 zonder sleep Z en nee +05:30 is geen moment in de tijd, het is een moment op een niet-gespecificeerde plek. Ik behandel elke API die naïeve tijdstempels retourneert als een bugrapport dat wacht om te worden ingediend. liever RFC 3339 (2026-02-25T14:30:00Z), wat het strikte, ondubbelzinnige profiel is van ISO 8601 dat het web daadwerkelijk gebruikt.

Wat moet ik doen als "het gisteren werkte"?

Verschil het. Don't theoretiseren - verspreid het.

Leg de reactie van de werkomgeving vast (of graaf de laatste goede uit je logs) en de reactie van de kapotte, en plaats ze naast elkaar. Negen van de tien keer is er precies één verschil en het staarde je binnen vijf seconden aan.

Voor JSON reikt u naar de JSON-differentiatie voor de tekstverschil. het ontleedt beide kanten en vergelijkt bouwwerk, wat betekent dat opnieuw geordende sleutels en verschillende inspringingen don't verschijnen als wijzigingen - alleen echte doen. Een tekstdiff van twee JSON-documenten dat een server die in een andere sleutelvolgorde is geserialiseerd, zal oplichten als een kerstboom en je niets vertellen.

Voor alles wat is't JSON - headers, onbewerkte lichamen, configuratiebestanden, curl uitvoer - gebruik de tekst diff. De specialiteit is de klasse van verandering, je ogen zijn fysiek niet in staat om te vangen: een sleepruimte, een tabblad dat vier spaties werd, een CRLF-lijn die naar binnen sloop van een Windows-machine, een gekrulde quote die een documentatieplaats in de plaats kwam van een rechte plaat toen je het voorbeeld kopieerde. Ik heb een heel stuk geschreven over Waarom het kijken naar tekstvergelijkingen mislukt, omdat het me een keer een escalatie van de ondersteuning kostte.

Waarom blijven mijn queryparameters aankomen verbroken?

Omdat URL-codering drie of vier subtiel verschillende smaken heeft en de stapel van iedereen een andere kiest.

De klassiekers, in ruwe volgorde van hoe vaak ze me hebben gebeten:

• + tegen %20. In een queryreeks, + historisch betekent een ruimte (de application/x-www-form-urlencoded conventie). In een padsegment, + betekent een letterlijk pluspunt. Dus een Base64-handtekening met daarin: +, neergezet in een queryreeks die niet is gecodeerd, komt met spaties erin en de handtekeningcontrole mislukt. Dit is echt een vervelende omdat de waarde eruit zien Recht in de logs.
• Dubbele codering. %2F HALD %252F Omdat twee lagen van uw stapel beide nuttig hebben gecodeerd. Het symptoom is een parameter die het percentage-tekens krijgt telkens wanneer het door een proxy gaat.
• een rauwe & binnen een waarde. Splitst uw parameter in twee. als name=Ben & Jerry is name=Ben plus een mysterieuze param genaamd Jerry.

Plak de URL in de URL-encoder en decodeer het. Als je het een keer decodeert, laat je het percentage ontvluchtingen achter, je hebt je dubbele codering gevonden. Dat is de hele diagnostiek.

Hoe debug ik een webhook die niet verifieert?

Dit is degene die scheidt "Ik begrijp http" van "Ik ben op afroep geweest".

Bijna elke webhook-provider ondertekent de payload met een HMAC en zet het resultaat in een header. Het is jouw taak om dezelfde HMAC te berekenen en te vergelijken. Als het niet overeenkomt, is de handtekening bijna nooit het probleem. De bytes zijn het probleem. Je hebt niet gehasht wat ze gehasht hebben.

De gebruikelijke verdachten:

1. Je hebt het geparseerde en opnieuw geserialiseerde lichaam gehasht. Je raamwerk heeft de JSON in een object geparseerd, riep je JSON.stringify() erop, en nu verschilt de sleutelvolgorde of de witruimte door één personage. je moet de hasj onvermengd verzoek body, bytes zoals ontvangen. In express betekent dat het vastleggen van de onbewerkte buffer voordat express.json() komt eraan; in Laravel betekent het $request->getContent(), niet $request->all().
2. Een achterban op een nieuwe lijn. Sommige klanten voegen er een toe. De aanbieder deed het niet.
3. Je hebt de hex-gecodeerde string gehasht in plaats van de onbewerkte bytes, of het vergelijken van hex met base64.
4. Charset. Het lichaam heeft een multi-byte karakter en iets onderweg getranscodeerd.

de Hash-generator is hoe ik dit isoleer: neem de exacte lichaamsreeks, hash het, vergelijk wat mijn code heeft geproduceerd voor wat het is inval was hetzelfde lichaam. Als die twee hashes verschillen, ziet mijn code de bytes niet dat ik denk dat het wordt gezien, en het probleem was helemaal nooit cryptografisch. (Ook het weten waard: als een provider nog steeds MD5- of SHA-1-handtekeningen aanbiedt, is dat een signaal over de leeftijd van hun platform. SHA-256 is nu de vloer.)

Wat leeft er nog meer in de debug-tabgroep?

De ondersteunende cast - minder glamoureus, verdient nog steeds zijn plaats:

• UUID-generator- voor een schone X-Request-ID Bij elke testoproep, zodat u het achteraf kunt over drie services. De moeite waard om te weten dat UUID's een specificatie hebben gekregen: RFC 9562 (2024) verouderd RFC 4122 en gestandaardiseerd uuidv7, die tijdgeordend is en daarom veel vriendelijker is voor de B-Tree-index van uw database dan Random V4. Als je vandaag een ID-schema voor een nieuwe tafel kiest, is dat degene om over te lezen. er is een Langere verdeling van UUID-versies Als je het wilt.
• Base64-converter- voor Authorization: Basic Headers (RFC 7617: het is base64(user:password), en ja, dat' s codering, niet beveiliging - TLS is wat het beschermt), en voor de inline blobs sommige API's dingen in JSON velden Base64 kost u ~33% grootte overhead, daarom een & quot; onverwacht groot" payload heeft vaak gewoon een bestand in de De Volledige Base64-gids Behandelt het onderscheid tussen Base64url dat mensen opheft.
• YAML-validator- omdat de helft van mijn API-storingen in het afgelopen jaar 't API-storingen waren. Het was een inspringfout met twee spaties in een CI-configuratie, en het eindpunt is helemaal nooit geïmplementeerd. (YAML heeft een smeriger faalmodus dan een kapotte build, maar: geldige YAML betekent iets dat je hebt gedaan't bedoeld. Ik schreef op waarom version: 1.10 wordt 1.1 nadat het me een deploying heeft gekost.)
• regex-tester- voorlopig moet u een verzoek-ID uit 900 regels logboek halen met een patroon waar u ' geen vertrouwen in heeft.
• CSV-kijker- voor het exporteindpunt waarvan u de output moet controleren voordat iemand deze in productie importeert.

Maakt het eigenlijk uit dat deze in de browser draaien?

Ja, en ik zeg dit zelfs als ik de site niet had gebouwd.

Bedenk wat je in een foutopsporingstool plakt Een JWT - dat is een Live-referentie totdat het vervalt. Een productie-API-reactie, namelijk klantgegevens: namen, e-mails, abonnementsstatussen. een webhook-body, die een betalingsrecord kan bevatten. a curl bevel met een Authorization koptekst er nog in.

Bedenk nu dat een tool aan de serverzijde dat per definitie allemaal ontvangt Niet kwaadwillig - gewoon architectonisch De plakken gaat in een HTTP-verzoek, raakt iemand' s backend, en landt in welke logboekregistratie ze ook uitvoeren Zelfs een nauwgezet eerlijke operator eindigt met je token aan toonder in een toegangslogboek dat ze nooit van plan waren bij te houden.

De tools op Toolz.dev doen het werk in JavaScript in uw tabblad Niets wordt geüpload, omdat er ' nergens naartoe kan worden geüpload - het parseren, de decodering, het hashen gebeurt allemaal op uw machine U don' u moet mij daarvoor op mijn woord geloven, ofwel: open DevTools, ga naar het tabblad Netwerk, plak een token en kijk naar een verzoek dat nooit komt Dat' is een audit van dertig seconden, en u moet het uitvoeren elk Tool waar je geheimen in plakt, de mijne inbegrepen. ik schreef op Hoe een client-side tool correct te verifiëren Om deze reden precies.

Als uw organisatie omgaat met persoonsgegevens van de EU, is dit & #39; t alleen hygiëne - het plakken van klantrecords in een server van derden is een verwerkingsactiviteit, met al het AVG-papierwerk dat dit met zich meebrengt Hulpmiddelen aan de clientzijde omzeilen de vraag door helemaal nooit een verwerker te worden.

Een workflow die echt blijft hangen

Zes stappen, in de volgorde voer ik ze uit als er iets in brand staat:

1. Leg de rauwe reactie vast. Volledige body, volledige headers, statuscode Niet uw app' s interpretatie ervan - de werkelijke bytes. curl -i of de netwerktab"kopie als curl."
2. formatteer het. JSON-formatter. kijk eens maken Voordat je naar de waarden kijkt. Is het veld dat je nodig hebt zelfs aanwezig?
3. Decodeer elke ondoorzichtige string. tokens door de JWT-decoder, Base64 Blobs door de Base64-converter, verminkte URL's door de URL-encoder. Ondoorzichtige snaren verbergen het antwoord verrassend vaak.
4. Verander elk nummer dat een tijd zou kunnen zijn, in een datum. tijdstempel converter. Tel eerst de cijfers.
5. diff tegen een bekende goede reactie. JSON-differentiatie. Als je geen goed antwoord hebt, is dit jouw teken om ze te gaan redden.
6. Ga nu pas je code lezen. Op dit punt weet u meestal de regel voordat u het bestand opent.

De volgorde is van belang. Stap 6 is waar ik vroeger begon, en daarom duurde die zaterdag acht uur.

Veelgestelde vragen

Wat zijn de beste gratis tools voor het debuggen van API's?

Voor de dagelijkse foutopsporing van API heb je vijf dingen nodig: een JSON-formatter en -validator, een JWT-decoder, een UNIX-tijdstempelconverter, een diff-tool en een URL-encoder/decoder. Alle vijf zijn gratis op Toolz.dev en worden volledig in de browser uitgevoerd. Voeg een hash-generator toe als u met ondertekende webhooks werkt en een YAML-validator als uw implementaties config-driven zijn.

Is het veilig om een JWT- of API-antwoord in een online tool te plakken?

Alleen als de tool client-side is Een JWT is een live-referentie en een API-reactie zijn meestal klantgegevens, dus een server-side tool betekent verzending van zowel naar een vreemde' s backend De Toolz.dev-tools verwerken alles in uw browser met JavaScript en verzenden niets via het netwerk - verifieer dit zelf door DevTools&#39 te openen; Netwerktab terwijl u plakt Voer diezelfde controle uit op elk hulpmiddel dat u gebruikt met gevoelige gegevens.

Waarom zegt mijn JWT "verlopen" toen ik het net genereerde?

De meest voorkomende oorzaak is een storing van een eenheden. de exp Claim is in seconden (RFC 7519 definieert het als een numerieke datum), maar JavaScript's Date.now() Retourneert milliseconden, dus als u ze direct vergelijkt, ziet elke token er verlopen uit. decodeer het token, lees exp, converteer het naar een echte datum met een tijdstempelconverter en controleer of het echt in het verleden is voordat u uw auth-code aanraakt.

Hoe weet ik of een UNIX-tijdstempel in seconden of milliseconden is?

Tel de cijfers. Tien cijfers is seconden, dertien is milliseconden, zestien is microseconden. Als er een datum uitkomt in 1970, gaf je seconden aan een milliseconde parser; als het uitkomt in het jaar 56122, heb je milliseconden gegeven aan een secondenparser. De tweede fout is gevaarlijker omdat niets een fout veroorzaakt.

Kan ik deze tools gebruiken om GraphQL API's te debuggen?

Ja. GrafQL-reacties zijn JSON, dus de JSON-formatter en JSON-diff werken ongewijzigd, en GraphQL gebruikt doorgaans dezelfde bearer-token-authenticatie die je decodeert met de JWT-decoder. Het enige echte verschil is dat GraphQL HTTP 200 retourneert met een errors array in plaats van een niet-2xx-status, dus formatteer altijd de body - de storing zit binnen de payload, niet in de statuscode.

Waarom mislukt mijn webhook-handtekeningverificatie altijd?

Bijna altijd omdat u andere bytes hasht dan de provider deed. Als uw raamwerk het JSON-lichaam heeft geparseerd en u het opnieuw hebt geserialiseerd voordat u hasht, is de witruimte of sleutelvolgorde veranderd en zal de HMAC nooit overeenkomen. Hash de RAW-verzoektekst precies zoals ontvangen en controleer op een trailing nieuwe regel die is toegevoegd door uw HTTP-client.

Wat is het verschil tussen base64 en base64url-codering?

Standaard Base64 (RFC 4648 §4) Gebruik + en / in het alfabet en de pads met =. BASE64URL (RFC 4648 §5) vervangt die met - en _ en laat meestal de opvulling vallen, dus de waarde is veilig om een URL of een JWT in te voeren. Het doorgeven van base64url-gegevens aan een strikte standaardbasis64-decoder produceert een fout of afval, daarom verslaat een speciale JWT-decoder een token met de hand decoderen.

Hoe debug ik een 401 ongeautoriseerde reactie?

Werk naar buiten vanaf het token. Decodeer het en controleer exp tegen de huidige tijd - een verlopen token is de meest voorkomende oorzaak, en het is onzichtbaar totdat u de claim omzet naar een leesbare datum Als het token live is, controleer dan de Authorization header zelf: het schema moet aanwezig en correct gespeld zijn (Bearer <token>, één spatie, geen aanhalingstekens), en een token geplakt van een terminal draagt vaak een achterblijvende nieuwe regel die de wedstrijd breekt. Bevestig daarna de aud en iss Claims komen overeen met wat de API verwacht, aangezien een geldig token dat voor een ander publiek is uitgegeven, precies als een slechte wordt afgewezen. Begin dan pas met het vermoeden van de server.

Hoe decodeer ik een JWT zonder bibliotheek?

Een JWT is drie basis64url segmenten verbonden door punten Split op de punten, dan base64url-decodeer de eerste twee - de header en de payload - en beide komen uit als gewoon JSON Het derde segment is de handtekening, en het decodeert niet in iets leesbaars omdat het ruwe bytes is in plaats van tekst Dit doet er meer toe dan het klinkt: het decoderen van een token vertelt je wat het beweert, niet of die claims waar zijn Voor het verifiëren van de handtekening is de emittent' s sleutel nodig en hoort thuis in uw server code, nooit in een browser tool Lees hier tokens om te debuggen; valideer ze in de applicatie.

Heb ik nog steeds postbode of slapeloosheid nodig als ik deze tools gebruik?

Ja - ze lossen verschillende problemen op Een API-client verzendt verzoeken; deze tools maken de reacties leesbaar In de praktijk gebruik ik de client om het verzoek af te vuren en de onbewerkte uitvoer te kopiëren, en ga vervolgens naar browsertools om het te formatteren, decoderen, converteren en verspreiden. Ze zitten naast elkaar in de workflow in plaats van elkaar te vervangen.