[keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator)

[Thomas Darimont]

Good point. Yes the main use case for PKCE are public clients / native apps.

However the recently published OAuth 2.0 Security Best Current Practice
(Draft 06 2018) [1] states:
"
2.1.  Protecting redirect-based flows
...
 Clients shall use PKCE [RFC7636] in order to (with the help of the
   authorization server) detect and prevent attempts to inject (replay)
   authorization codes into the authorization response.  The PKCE
   challenges must be transaction-specific and securely bound to the
   user agent, in which the transaction was started.  OpenID Connect
   clients may use the "nonce" parameter of the OpenID Connect
   authentication request as specified in [OpenID] in conjunction with
   the corresponding ID Token claim for the same purpose.

Note: although PKCE so far was recommended as mechanism to protect
   native apps, this advice applies to all kinds of OAuth clients,
   including web applications.
"
The last "Note" section was what inspired me to look into PKCE support for
server-side adapters as well.
But I generally agree that this is probably better suited for the JS / CLI/
keycloak-installed adapters.

[1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06

On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> As PKCE is aimed at public clients why is there a need to add support for
> this to the Java adapters? Makes more sense to add this to the JavaScript
> adapter and CLI/desktop adapter.
>
> On 30 May 2018 at 07:47, 乗松隆志 / NORIMATSU，TAKASHI <
> takashi.norimatsu.ws at hitachi.com> wrote:
>
>> Hello,
>>
>> I've encountered the same problem and gave up.
>>
>> At that time, the naive idea had hit on me.
>> * prepare some concurrently accessible singleton (line
>> KeycloakDeployment) from OAuthRequestAuthenticator
>> * store generated codeVerifier on it with state parameter value as its
>> key.
>>
>> But, considering the nature of codeVerifier, the followings are required
>> for such the store
>> * codeVerifier should be treated the same secure levels as client
>> credentials
>> * codeVerifier should be short-lived and deleted after its life the same
>> as Authorization Code
>>
>> Therefore, It might be better to create an tentative instance whose
>> lifetime is between issuing Authorization Code Request and issuing Token
>> Request. And, it should be identified and only accessible from the session
>> instance who issued Authorization Code Request.
>>
>> However, I'm afraid it might be difficult to accomplish it in generic
>> fashion. We need to implement the above each type of client adapter.
>>
>> Best regards,
>> Takashi Norimatsu
>> Hitachi Ltd.,
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org <
>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas Darimont
>> Sent: Wednesday, May 30, 2018 9:02 AM
>> To: keycloak-dev <keycloak-dev at lists.jboss.org>
>> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters
>> (OAuthRequestAuthenticator)
>>
>> Hi there,
>>
>> I was recently playing with the PKCE support in Keycloak (server) which
>> worked quite well.
>> However the support for client / adapters seems to be quite limited at
>> the moment...
>>
>> I think support for PKCE to all? java adapters could be added quite easily
>> - I could provide a
>> PR but I'm currently stuck with finding a generic way to store the
>> codeVerifier generated for the login redirect for later retrival for the
>> code2token exchange.
>>
>> Do you have any recommendations for this?
>>
>> I created the following JIRA issue (with some comments) to track this:
>>
>> https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467
>>
>> Cheers,
>> Thomas
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>>
>> https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>