[keycloak-dev] Java Adapter Nonce Support

[Pedro Igor Silva]

Hi,

As per the latest OAuth2 Security BCP, clients using code grant should
prefer PKCE. We already have support for it on the server and also on the
JS adapter.

Doesn't make more sense to support PKCE instead of nonce? It helps both
code replay and injection attack.

On Tue, Jul 30, 2019 at 1:09 PM D. Richter <richter.wuensdorf at googlemail.com>
wrote:

> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>