JWT
What are JSON Web Tokens (JWT)? How they are used in web applications for authentication and authorization? Discuss some advantages and potential security concerns associated with JWT? Mitigations?
Last updated
What are JSON Web Tokens (JWT)? How they are used in web applications for authentication and authorization? Discuss some advantages and potential security concerns associated with JWT? Mitigations?
Last updated
Source: https://jwt.io/introduction
The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
{ "alg": "HS256", "typ": "JWT" }
After which, it is Base64Url encoded to form the first of the 3 parts
Claims are the second part of the token
They are statements of the entity(Typically user) + additional data
There are 3 types of claims: registered, public, and private claims.
These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims.
Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience), and others.
These can be defined at will by those using JWTs.
To avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
Private claims:
These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.
{ "sub": "1234567890", "name": "John Doe", "admin": true }
After which, it is Base64Url encoded to form the second of the 3 parts
To create the signature, the following are used to create a signature
encoded header,
encoded payload,
a secret
algorithm specified in the header
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Authentication
When the user successfully logs in using their credentials, JSON Web Token will be returned.
JWT is smaller when compared to Simple Web Tokens (SWT) and Security Assertion Markup Language Tokens (SAML).
Signing process for JWT is more secured than signing XML format
Easier mapping
XML doesn't have a natural document-to-object mapping
JSON has :)
Source: https://portswigger.net/web-security/jwt
Man-In-The-Middle attacks
JWT header parameter injections
Brute-forcing secret keys
JWT algorithm confusion
Use an up-to-date library for handling JWTs and make sure your developers fully understand how it works, along with any security implications. Modern libraries make it more difficult for you to inadvertently implement them insecurely, but this isn't foolproof due to the inherent flexibility of the related specifications.
Make sure that you perform robust signature verification on any JWTs that you receive, and account for edge-cases such as JWTs signed using unexpected algorithms.
Enforce a strict whitelist of permitted hosts for the jku header.
Make sure that you're not vulnerable to path traversal or SQL injection via the kid header parameter.
Always set an expiration date for any tokens that you issue.
Avoid sending tokens in URL parameters where possible.
Include the aud (audience) claim (or similar) to specify the intended recipient of the token. This prevents it from being used on different websites.
Enable the issuing server to revoke tokens (on logout, for example).
Beckham🐱👤
