[keycloak-dev] Java Adapter Nonce Support
D. Richter
richter.wuensdorf at googlemail.com
Tue Jul 30 11:02:26 EDT 2019
Hi Devs,
i did a pull request https://github.com/keycloak/keycloak/pull/6154 that
was declined as it needed a bit more discussion.
A controverse point was to add a configuration with the remark to always
add the nonce to authentication requests just like here:
https://lists.jboss.org/pipermail/keycloak-dev/2018-February/010447.html
However, adding a nonce without checking it might work when the
authentication flow requires a nonce but it's useless when it is not
checked.
This is the oAuth 2.0 spec:
https://tools.ietf.org/html/rfc6819#section-4.6.2
As described the replay protection uses a nonce so requests can only be
done once. This is the reason you should never make this the default
behaviour for an adapter.
The second topic is how to do it. The oAuth 2.0 spec does not describe how
to handle the nonce on the client side. My first idea was to use the
current authentication session which has some limitations: you can only
make a valid request when your adapter holds the session and also validates
the IDP token. This all falls apart when 1) your session is timed out but
your token is still valid 2) the Token has not been requested by the same
adapter.
To remove these limitations and still ensure the prevention of replay
attacks it would be necessary for the adapter to persist the nonce and the
expiration date of the access token. When a resource request comes with a
nonce, you allow access but also store the nonce and token expiration. When
the nonce has been stored already -> access denied. A cleanup mechanism
would also be required to keep the database clean from old nonce markers
where the token is already expired.
This variant would require a persistence layer - something i have no answer
for, especially when i think of the various existing application servers
and their Keycloak adapters.
Another option might be the Cookie. As long as it's required for resource
requests and cannot be manipulated this would be a #1 choice because it
relies on code that is already there. I'm just not sure if the premises are
given (secure and non optional cookie).
Kind Regards,
Dennis Richter
More information about the keycloak-dev
mailing list