In this article we will try to understand the difference between client ID-Client secret and signed JWT authentication Scheme in RedHat SSO (aka Keycloak).
1) Presentation
When dealing with Oauth2/openID RH-SSO provides 3 possible authentication schemes which are:
- public: does not require a secret
- confidential: client requires a secret to initiate the login protocol
- bearer-only: client are web services that never initiates a login (example: an application connnecting to a database)
The bearer-only type is special kind of confidential client with no login, and is for example used for an application to connect to a database service.
Confidential clients also comes in 2 different ways of dealing which are:
- client_id/client_secret
- signed JWT
2) Using clientid/client secret method
The most widespread and simplest method to configure is client_id/client_secret.
Most of social login broker such as facebook, google, twitter provides this authentication scheme.
Upon registration a clientID/client secret is provided to you.
The client secret is shared between the server which has delivered it to you, and yourself.
The Client secret is in fact the symetric key which is used to encrypt exchanges between the server and you.
The resource server knows this secret key, so it performs the same calculations as the client did using the same params.
If everything matches it proceeds with the request.
The symetric key exchange encryption is done using HMAC algoritm, and the secret key is never sent on the wire.
Using HMAC symetric key algoritm garantees that the messge is not tampered with (case of Man in the middle attack),
but does not provide signature verification.
It is not possible to assert the identity of the customer which has sent to you the request.
If the clientID/client secret got stolen, it could be possible to be resued by any 3rd party customer.
3) signed JWT
The customer client application implements a keystore with secret key/public key.
RH-SSO needs to get hold of the customer public key client application
RH-SSO offers 2 ways to get hold of the public key:
-uploading the client application public in RH-SSO
-provding a client application JWKS URI, where RH-SSO is able to retrieve the public key.
The advantage of using a RH-SSO using a JWKS URI is that the URL remains the same if client is rotating the key.
Upon client application key rotation RH-SSO will upload automatically the new certificate.
If the public key was to be loaded in RH-SSO, it means that upon each customer app key rotation, the new public key
has to be uploaded in RH-SSO.
As signed JWT is based on asymetric PKI, it provides signature verification, which allows to perform non repudiation validation.
Usual asymetric algorithm provided are RSA and EC (elliptic curve).
RH-SSO only implemennts RSA algorithms.
Another important fact to have in mind is that asymetric algorithms are much much more slower than symetric algorithm.
(About 1000 times slower).
4) When shoudl clientId/client secret be used versus signed JWT method
Well, it really depends of what you need to do.
Signed JWT is based upon asymetric algoritm (RSA based).
It provides signature verification, but is also very slow and CPU computation intensive
ClientID/Client secret is much more lightweight and more easy to deploy and provides integrity (message is not compromised).
It does not provide signature verification, and there is always a possiblity of the key being stolen.
It is also very fast.
Note:
All the concepts described here have been described with the focus of RH-SSO, but can also apply to any other system
leveraving Oauth2,as those concepts are quite general
5) Pointers
JANUA provides better security, build relationships, and enable new cloud, mobile, and IoT offerings from any device or connected thing.
- New Keycloak online training - 19 janvier 2022
- Sizing Keycloak or Redhat SSO projects - 8 juin 2021
- Keycloak.X Distribution - 28 janvier 2021