Microsoft.IdentityModel.JsonWebTokens erstellt und validiert JWTs mit JsonWebTokenHandler und einem Objekt TokenValidationParameters; AddJwtBearer in ASP.NET Core leitet Anfragen durch diesen Handler, sodass seine Standardeinstellungen die der meisten .NET-APIs sind. Version 8.23.0 signierte und validierte mit den Familien HS, RS, PS und ES; einen Sicherheitsschlüsseltyp für EdDSA gibt es im Paket nicht.
ValidAlgorithms ist standardmäßig null, und der Schlüssel entscheidet: Ein RS256-Token und ein HS256-Token, das mit dem PEM-Text des EC-Schlüssels gefälscht wurde, scheiterten beide an einem EC-Schlüssel mit IDX10517: Signature validation failed. Unsignierte Tokens scheitern mit IDX10504, sofern RequireSignedTokens nicht auf false gesetzt ist. Die Lücke liegt bei der Bindung an die Kurve: Mit einem P-384-Schlüssel ließ sich ES256 signieren, und derselbe Handler validierte das resultierende Token – was andere Bibliotheken wie jose, PyJWT und golang-jwt ablehnen. Setze ValidAlgorithms und verwende Schlüssel der richtigen Größe, wie es das Beispiel tut.
Bei der Gültigkeitsdauer verhält sich die Bibliothek umgekehrt wie die meisten anderen: exp ist Pflicht (IDX10225), und TokenValidationParameters.DefaultClockSkew beträgt fünf Minuten, sodass ein Token nach seinem Ablauf noch bis zu fünf Minuten lang funktioniert. Für kurzlebige Access Tokens ist das großzügig; setze ClockSkew explizit. CreateToken fügt exp auch dann hinzu, wenn Expires nicht gesetzt ist.
ES256-Signaturen sind das 64 Byte lange rohe r‖s, das JWS verlangt, passend zum Standard der .NET-eigenen Klasse ECDsa; eine DER-Signatur scheitert mit demselben IDX10517 wie eine Fälschung. Fehlermeldungen verbergen den Inhalt des Tokens als [PII of type ... is hidden], sofern IdentityModelEventSource.ShowPII beim Debuggen nicht aktiviert ist – dekodiere das Token stattdessen im JWT-Debugger und prüfe die Schlüssel eines Anbieters mit dem JWKS-Checker.