I'm trying to better understand JWT and how to properly use it.
In common JWT use cases (like JWT-based authentication or JWT access token in oauth), does it make sense to verify a JWT token client-side? In particular, I'm asking this to better understand the requirements on the public and private keys that are involved in the JWT signing and encryption. If the clients never need to verify the JWT signature than the server does not need to make its public key available. If this is true, I don't even need a full blown X.509 certificate: a bare public/private key pair or a self signed cert would suffice, right?
So all this boils down to the question: what is the right way to deal with asymmetric keys used in JWT? Do I need a public key infrastructure or is a simple private/public key pair enough?
I understand that JWT specs do not cover this: yet I'm curious to know what the common practices are in real JWT usage.
Of course this question has nothing to do with the certs involved in https: I'm just talking about the keys used in JWT signature and encryption.
does it make sense to verify a JWT token client-side?
It makes sense if you use the token payload data to perform an operation in client side, and you need to trust the token. If you use the token for authenticate in a server, then let the server verify the signature.
if this is true, I don't even need a full blown X.509 certificate: a bare public/private key pair or a self signed cert would suffice, right?
Do I need a public key infrastructure or is a simple private/public key pair enough?
You can use either a trusted certificate, a self-signed certificate or simply a RSA keypair. Usually is used an autogenerated keypair. But if you do not plan to verify the signature on client, you can just use a HMAC symmetric key (not assymetric
Related
I'm receiving a JWT from Microsoft Azure, and I need to verify it on my server. The JWT is signed using RS256, i.e. using asymmetrical private/public key encryption.
I know that various libraries exist that can be used to verify a JWT signature directly from our backend server. But I'm curious if it wouldn't be possible to verify the JWT signature using an online service? Since it's using RS256 and not HS256, only public keys are involved in the verification process, no private keys or other secrets.
It seems like it would be simple to put up a REST service that can take an asymmetrically signed JWT, verify the signature and give back true/false. But when Googling I can't find any such services. Not even from big names in the JWT-world, like Auth0.
Why is that? Is there some security concern with letting another server verify the JWT signature?
I'd like to create a X.509 public key certificate to verify signatures, esp. JWT Tokens.
I'd like to know which properties and extensions properties to set to which values on the certificate to restrict it for JWT verification.
Unfortunately, the specification of X.509 extensions is pretty verbose. So, I'd also be very thankful for a brief overview of available X.509 extensions, properties and their meaning.
JWT signing and validation with asymmetric keys is done using exclusively a key pair, not certificates. It is only needed a public key to validate the token signature.
The public key can be contained in a certificate in order to be sent to the verification party, but this is not really needed, and the recipient is not obliged to perform the validation with respect to any attribute or extension that the X509 certificate may have.
The type of certificate extensions you need to enforce such restriction is... Key Usage and/or Extended Key Usage extensions. For any kind of digital signature, you need at least the Key Usage called... digitalSignature, as specified in RFC 5280. Standard (Extended) Key Usage extensions are all specified in ยง 4.2.1.3 and 4.2.1.12 of the RFC.
You can always avoid certificates for the sake of simplicity, by maintaining a truststore (a static list) of public keys (or fingerprints if you want to optimize memory/disk usage) on the JWT verifier's side. But this has some limitations, such as:
No standard revocation mechanism: if the signing key has been compromised, how does the verifier become aware of that? With certificates, you have the possibility to revoke certificates, and verifiers use standard OCSP or CRL to verify the revocation status.
You have to know in advance all public keys potentially used for JWT signing. This is not always the case. (E.g. in some cases, all you want to know as a verifier is that the key belongs to some trusted organisation's entity and that it has been allowed for signing.)
If the list of public keys is/becomes too big, it is hardly manageable.
If the keys change too often (remember that keys should be renewed regularly), it is hardly manageable.
Therefore, if such limitations affect you, X.509 certificates offer a more scalable and flexible solution, but with an extra layer of complexity of course. With certificates, it works like this:
Each JWT issuer has a certificate issued by one or more Certificate Authorities (CA)
JWT verifiers should trust these CAs (list of trusted CAs), instead of trusting each JWT issuer's certificate specifically.
JWT include the signer's certificate (or certificate chain if you use sub-CAs) in the x5c header parameter of the JWS header as per RFC 7515 (X.509 Certificate Chain), so that the verifier can link the certificate (chain) to one of the trusted CAs.
more specific: can I use jwt .net implementation to create a token and use jwt node.js implementation to verify the token?
The implementation details does not affect to the format or content of JWT, so you can perfectly use .net (A) to generate and node.js (B)to verify.
For B to be able to verify the token, use a RSA asymmetric key pair, public and private. A signs with the private key and B verifiew with the public.
It would be possible to share a HMAC symmetric key between A and B. But then it is needed to consider the security issues of having the key in both systems and how to synchronize them.
Recently, I'm trying to implement an OAuth2.0 server using JSON Web Token (JWT) as access token. I'm very confused about the self-contained feature of JWT. I notice that JWT can be verified anywhere, not mandatorily in authorization server because it is self-contained. How does this feature work? What claims should be included in JWT in order to realize self-contained feature?
Another question is that, if JWT is stateless, it means the server should not store the JWT. Then how is the JWT verified? Can't it be easily forged?
I'm the rookie in this field, I wish someone could help me out:)
JWT contains claims that can be signed, encrypted or both.
These operations are performed using cryptographic keys. Keys can be symmetric (e.g. octet keys) are Asymmetric (e.g. private/public key pairs such as RSA or EC keys).
When you want to verify a JWT (i.e. a JWS), you have to perform the following steps:
Check the header (algorithm is supported, critical claims are in the payload and their value are understood).
Check the claims (especially exp, iat, nbf, aud).
Check the signature.
To check the signature, you need the key and, depending on the algorithm, this key can be
The symmetric key
The public key if asymmetric
When you want to allow third party applications to verify your JWT, you will use asymmetric keys and share the public key with the third parties.
As public keys cannot be used to sign, third parties cannot forge a valid token with custom claims.
The way you share the keys is up to you. The common way is to provide an URL where applications will retrieve them (e.g. Google keys at https://www.googleapis.com/oauth2/v3/certs).
I am implementing a REST service which has RESTful authentication using jwt based on suggestions from this and this answers.
In constructing the JWT I have decided to sign it using an rsa public private pair rather than hmac for the obvious benefit of being able to keep my signing key fully private because I don't trust the clients that I will need to share the validation key with.
My question is, since normal https server certificates already use rsa keys, would it be acceptable to use that same key pair to sign a JWT token? One advantage I can see is that I will not have to maintain two certificates and mechanisms for sharing the public key with the client are already well established.
PS In case I sign the JWT with a new specific key pair, what is the best way of sending the public key to the client for use in verifying the token?