JSON Web Tokens (JWT) are a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
Structure of JWT
A JWT is composed of three parts, separated by dots (.), which are:
- Header: 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.
- Payload: The payload contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.
- Signature: To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.
The structure looks like this: xxxxx.yyyyy.zzzzz
Example in Action
- Header: A base64 encoded JSON string that specifies the algorithm used for the token. Example:
{"alg": "HS256", "typ": "JWT"}. - Payload: Another base64 encoded JSON string containing the claims. This could include user identifier, authentication provider, project details, etc. Example:
{"userId": "12345", "authProvider": "Firebase", "exp": "16000000"}. - Signature: A hashed combination of the header, the payload, and a secret key, all encoded together.
Verification and Trust
JWTs are trusted until their expiration is reached, or the signing key is compromised. Importantly, while the information contained in a JWT can be read by anyone, it cannot be altered without access to the signing key, ensuring the integrity of the token.
In the context of using Firebase, for example, the signing keys (for verifying token integrity) are rotated regularly and are publicly accessible for verification purposes but the signing key used by Firebase to create tokens is kept private.
Authentication Flow with JWT
Once a user is authenticated, they receive a JWT from Firebase. This token can then be used to make requests to a backend server. The server will:
- Verify that the token belongs to the specified project.
- Check that the token has not expired.
- Validate the signature to ensure the token has not been tampered with.
This process can often be handled with a single function in the Firebase Admin SDK, and it does not necessarily require a database or queries, though the SDK may periodically make requests to retrieve the public key for signature verification.
Security Considerations
It's crucial to understand that JWTs are not encrypted but signed. This means the contents of a JWT can be read by anyone, but not altered or forged without the secret key used to sign it. When using symmetric signing (e.g., HMAC), the same secret is used to sign and verify the token. For added security, asymmetric keys (public/private key pairs) can also be used, where the public key can safely be distributed for verifying tokens, but only the holder of the private key can sign them.
In summary, JWTs offer a robust method for handling authentication and information exchange in your applications, providing a mechanism to ensure data integrity and trust across different systems.
