I have created a new realm in Keycloak and in the admin tab Keys -> Active I can see three entries: RSA, HMAC, AES.
Whenever a JWT token is generated the signature algorithm used is RSA. How can I use HMAC instead?
I had the same question and found the following answers:
The latest documentation says that only rsa is supported for access tokens.
(http://www.keycloak.org/docs/3.3/server_admin/topics/realms/keys.html)
There is the plan to sign refresh tokens with hmac. Look at this user mailing list entry for more details:
"It is not great to sign accessTokens and idTokens by HMAC anyway since the
applications will need to have access to realm signing key. As it is
symmetric stuff. This can be security hole as then the application can
generate and sign tokens by itself. Hence we rather rely on the
asymetric cryptography - Keycloak signs tokens with private key and
application has just public key to verify signatures."
http://lists.jboss.org/pipermail/keycloak-user/2017-May/010809.html
Here is the JIRA for it:
https://issues.jboss.org/browse/KEYCLOAK-4623 and internally
https://issues.jboss.org/browse/KEYCLOAK-4622
In Keycloak 20.0.3 you need to go to "Tokens" tab and choose HS256 algorithm:
Related
I am newbie in JSON web token and micro services. I read in an articles that if i share the private, all services can verify user on their own. Then i tried to implement an application to practice.
Basically, I have two services A and B. A is used for authentication. Then, I tried implement a API that required authentication in service B. But when I used a token generated by authentication A in API, 401 status code and "Invalid signature." were returned.
So anyone can explain to me what I did wrong?
"Invalid signature" implies that the secret key that you used to encode the token doesn't match with the secret key you used for decoding it.
Make sure that the secret you are using for encoding and decoding are same.
For more info visit the JWT's site.
First of all the service to service communication only need public key to be shared in case of an asymmetric key pair such as RSA or ECDSA. The public key shared can be used to verify the signature and each service needs to sign JWT using their private key. You have to take care of securing the private key and make public key accessible to other services.
Verifying the user is a completely different use case. The user existence should be checked in database and a password check can be made which is authentication is all about. The JWT can be used to pass the user information along with access right with a signature done by the application using private key so that no one able to generate the same token. NOTICE : Signature is done using private key. In this way you have both authentication and authorisation using JWT.
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?
Although Thinktecture.IdentityServer supports signing a jwt using a symmetric key, the OidcClient class does not support validating a token using one - it only supports validating tokens signed using a certificate.
Is this deliberate and are there problems or any limitations with signing a jwt with the client secret?
I am getting some push back with requiring client apps to have a certificate and if I can avoid it without compromising security I would like to do so.
IIRC OidcClient is quite old - we just did not implement it. And you apps don't need a certificate, they just need to be able to verify a signature using asymmetric crypto.
Using a symmetric key makes only sense for server-based apps since that key must be stored securely (otherwise anyone who reverse engineers the app can create valid identity tokens).
The other option is to send the id token back to idsrv to validation (for clients that don't have the required crypto libraries). This endpoint does not exist currently in beta 1 - but is on our todo list.