FACHWISSEN · TECHNIK & SICHERHEITINSIGHTS · TECHNOLOGY & SECURITYAPPROFONDIMENTI · TECNOLOGIA E SICUREZZACONOCIMIENTO · TECNOLOGÍA Y SEGURIDAD
Zugriffstoken prüfen: Warum eine gültige Signatur nicht jede Anfrage erlaubtValidating access tokens: why a valid signature does not permit every requestValidare i token di accesso: perché una firma valida non autorizza qualsiasi richiestaValidar tokens de acceso: por qué una firma válida no autoriza cualquier solicitud
Ein Dienst erhält ein signiertes Zugriffstoken. Die Signaturprüfung ist erfolgreich. Trotzdem kann die konkrete Anfrage unzulässig sein: Ein Token muss zum empfangenden Dienst, zum vorgesehenen Zeitraum und zur benötigten Berechtigung passen. Diese Prüfungen werden im ausführenden System durchgesetzt und nicht allein der Oberfläche überlassen.
Herausgeber und Ziel prüfen
Bei signierten, strukturierten Zugriffstoken gehören die Prüfung des erwarteten Herausgebers und des vorgesehenen Empfängers zum Validierungskonzept. Ein Token für einen anderen Dienst wird nicht dadurch passend, dass es mit einem grundsätzlich bekannten Schlüssel signiert wurde. Die Regeln richten sich nach dem verwendeten Tokenprofil und werden vor der Integration gemeinsam festgelegt.
Gültigkeit und Berechtigung unterscheiden
Eine Ablaufzeit begrenzt die zeitliche Verwendung. Berechtigungsangaben beschreiben den erlaubten Umfang. Beide erfüllen verschiedene Aufgaben. Aus einer bestandenen Zeitprüfung folgt deshalb nicht, dass beispielsweise eine Schreiboperation erlaubt ist. Auch die Zuordnung zur konkreten Ressource kann eine weitere Entscheidung verlangen; allgemeiner Lesezugriff erlaubt nicht zwangsläufig den Zugriff auf jeden Datensatz.
Negative Fälle gezielt testen
Fiktives Beispiel: Eine Anwendung darf Datensätze lesen. Ein Test bestätigt den Lesezugriff, prüft aber keine Änderung. Erst ein zusätzlicher negativer Test zeigt, ob derselbe Zugriffstoken auch ungewollte Schreibzugriffe zulässt. Weitere Testfälle betreffen einen falschen Empfänger und ein abgelaufenes Token. Das erwartete Ergebnis wird jeweils vor dem Test definiert.
Tokens als schützenswerte Daten behandeln
Wer ein Bearer-Token besitzt, kann es grundsätzlich im damit erlaubten Umfang einsetzen, ohne einen zusätzlichen Schlüsselbesitz nachzuweisen. Solche Werte gehören daher nicht in Bildschirmfotos, allgemeine Protokolle oder Fehlerberichte. Ein nachvollziehbares Prüfergebnis dokumentiert den geprüften Fall und die Entscheidung, statt das vollständige Token zu speichern. Andere Tokenarten und zusätzliche Bindungen erfordern entsprechend angepasste Prüfregeln.
A service receives a signed access token and its signature check succeeds. The particular request may still be unauthorised: the token must match the receiving service, the intended time period and the permission required. Enforcement belongs in the executing system, rather than relying only on an interface hiding unavailable actions.
Check issuer and intended recipient
With signed, structured access tokens, validating the expected issuer and intended audience forms part of the validation design. A token issued for another service does not become suitable merely because a generally recognised key signed it. The selected token profile determines the applicable checks, which should be agreed before integration.
Distinguish validity from permission
An expiry time limits when a token can be used. Permission claims describe the allowed scope. These checks serve different purposes. Passing a time check does not establish permission to perform a write operation. The specific resource may also require another authorisation decision: general read access does not necessarily permit reading every individual record.
Test negative cases deliberately
In a fictional example, an application may read records. A test confirms reading but never attempts modification. An additional negative test checks whether the same token unintentionally permits writes. Other cases include an incorrect audience and an expired token. Define the expected decision before executing each test so that rejection is tested as deliberately as successful access.
Treat tokens as sensitive data
Possession of a bearer token generally allows its holder to use the permissions it grants without separately proving possession of a cryptographic key. Such values therefore do not belong in screenshots, general logs or error reports. A traceable test result records the scenario and decision rather than the complete token. Other token types and additional bindings require suitably adapted validation rules.
Un servizio riceve un token di accesso firmato e la verifica della firma riesce. La richiesta concreta può comunque non essere autorizzata: il token deve corrispondere al servizio destinatario, al periodo previsto e al permesso richiesto. I controlli devono essere applicati nel sistema che esegue l’operazione, senza limitarsi a un’interfaccia che nasconde le azioni non disponibili.
Verificare emittente e destinatario previsto
Per i token di accesso firmati e strutturati, verificare l’emittente atteso e il destinatario previsto fa parte del progetto di validazione. Un token emesso per un altro servizio non diventa adeguato soltanto perché è firmato con una chiave generalmente riconosciuta. I controlli applicabili dipendono dal profilo di token scelto e devono essere concordati prima dell’integrazione.
Distinguere validità e autorizzazione
La scadenza limita quando il token può essere utilizzato. Le informazioni sui permessi descrivono l’ambito consentito. Questi controlli hanno funzioni diverse. Superare la verifica temporale non dimostra quindi il permesso di scrivere. La risorsa specifica può richiedere un’ulteriore decisione di autorizzazione: un accesso generico in lettura non permette necessariamente di leggere ogni singolo record.
Verificare deliberatamente i casi negativi
In un esempio ipotetico, un’applicazione può leggere record. Un test conferma la lettura ma non tenta mai una modifica. Un ulteriore test negativo verifica se lo stesso token consenta involontariamente anche scritture. Altri casi riguardano un destinatario errato e un token scaduto. Si definisce prima l’esito atteso di ogni prova, così da verificare il rifiuto con la stessa attenzione dell’accesso riuscito.
Trattare i token come dati da proteggere
Il possesso di un bearer token consente in generale di usarne i permessi senza dimostrare separatamente il possesso di una chiave crittografica. Questi valori non devono quindi comparire in screenshot, log generici o rapporti di errore. Un risultato di test tracciabile registra scenario e decisione, anziché conservare il token completo. Altri tipi di token e vincoli aggiuntivi richiedono regole di validazione adeguate.
Un servicio recibe un token de acceso firmado y la comprobación de la firma es correcta. La solicitud concreta puede seguir sin estar autorizada: el token debe corresponder al servicio receptor, al periodo previsto y al permiso necesario. Los controles deben aplicarse en el sistema que ejecuta la operación, sin depender únicamente de una interfaz que oculta las acciones no disponibles.
Comprobar el emisor y el destinatario previsto
En los tokens de acceso firmados y estructurados, validar el emisor esperado y la audiencia o destinatario previsto forma parte del diseño de validación. Un token emitido para otro servicio no se vuelve adecuado solo porque lo haya firmado una clave reconocida. Las comprobaciones aplicables dependen del perfil de token elegido y deben acordarse antes de la integración.
Distinguir la validez del permiso
La caducidad limita cuándo puede utilizarse un token. Las declaraciones de permisos describen el ámbito autorizado. Estos controles cumplen funciones diferentes. Superar la comprobación temporal no demuestra por tanto autorización para escribir. La asignación a un recurso concreto puede requerir otra decisión de autorización: un permiso general de lectura no permite necesariamente leer cada registro individual.
Probar deliberadamente los casos negativos
En un ejemplo hipotético, una aplicación puede leer registros. Una prueba confirma la lectura, pero nunca intenta modificarlos. Una prueba negativa adicional comprueba si el mismo token permite escribir de forma no prevista. Otros casos incluyen un destinatario incorrecto y un token caducado. El resultado esperado se define antes de cada prueba para verificar el rechazo tan deliberadamente como el acceso correcto.
Tratar los tokens como datos que deben protegerse
Poseer un bearer token permite en general utilizar los permisos que concede sin demostrar por separado la posesión de una clave criptográfica. Por ello, estos valores no deben aparecer en capturas de pantalla, registros generales ni informes de error. Un resultado de prueba trazable documenta el caso y la decisión en lugar de almacenar el token completo. Otros tipos de token y vinculaciones adicionales necesitan reglas de validación adaptadas.