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

Stian Thorgersen sthorger at redhat.com
Tue Jun 12 11:35:13 EDT 2018 

There's a JavaScript adapter test in the base testsuite. On my phone now so
can't find the correct name. Probably called JavaScriptAdapterTest or
something like that.

On Fri, 8 Jun 2018, 18:35 Thomas Darimont, <thomas.darimont at googlemail.com>
wrote:

> Hi Marek,
>
> thanks for your helpful feedback!
> I extracted the generateRandomData() function from the
> generateCodeVerifier() function, which could be
> reused for state and UUID generation. I also added a fallback in case
> Uint8Array isn't available.
>
> I created a PR with the current implementation for KEYCLOAK-1033 (the
> issue subject should be adapted to this)
> https://github.com/keycloak/keycloak/pull/5255
>
> What's the best way to implement an automated for this?
>
> Cheers,
> Thomas
>
> On Wed, Jun 6, 2018 at 9:12 AM Marek Posolda <mposolda at redhat.com> wrote:
>
>> Hi Thomas,
>>
>> I think it is great and will be good to support this in our javascript
>> adapter OOTB.
>>
>> Few comments:
>> - In keycloak.js, we use "createUUID()" function to generate "nonce" and
>> "state" . IMO it will be good if all the things (nonce, state,
>> codeVerifier...) are generated through same mechanism. I guess that we
>> can use "window.crypto" or "window.msCrypto", but if none of them is
>> available, then just fallback to what is currently used in
>> "createUUID()" ? Also change the current generating of "nonce" and
>> "state" to this as I suppose that "window.crypto" or "window.msCrypto"
>> are safer alternatives than our current "createUUID()" ?
>>
>> - I have same concern as you about localStorage, but don't have any
>> better alternative... No idea if sessionStorage is better.
>>
>> - We should document what browsers supports it. I guess that due to
>> fallback for crypto/msCrypto, the "plain" method shouldn't be an issue
>> for any browser as codeVerifier will be always generated just fine? But
>> I guess that S256, which requires this "Uint8Array" stuff may have
>> compatibility issues? Or am I wrong here? The issue is, that people can
>> still use very old browsers (For example Windows XP with IE6) and not
>> sure how bad it is if those people with old browsers can't authenticate...
>>
>> Marek
>>
>>
>> On 05/06/18 21:33, Thomas Darimont wrote:
>> > Hello,
>> >
>> > I gave it another spin and tested it with a whole bunch of browsers
>> > - Windows (IE11, Edge, Firefox, Chrome)
>> > - Linux (Chrome, Firefox)
>> >
>> > Current changes: (Added IE11 Support)
>> >
>> https://github.com/keycloak/keycloak/compare/master...thomasdarimont:poc/keycloak-js-pkce-support?expand=0
>> >
>> > If you want to give it a try, you could use the js-console example from
>> >
>> >
>> https://github.com/keycloak/keycloak/blob/master/examples/js-console/src/main/webapp/index.html
>> > and just copy the keycloak.js with the PKCE support into the webapp
>> folder
>> > an include the script from there.
>> >
>> > In the initOptions for Keycloak, just add "pkceMethod: 'S256'", e.g.:
>> >
>> >      var initOptions = {
>> >          responseMode: 'fragment',
>> >          flow: 'standard',
>> >          pkceMethod: 'S256'
>> >      };
>> >
>> > If you look at your browser dev-tools, you should now see,
>> code_challenge
>> > and code_challenge_method parameters added to your
>> > /auth url. Additionally a code_verifier parameter should be sent with
>> the
>> > /token POST request.
>> >
>> > Some additional remarks:
>> >
>> > In order to support IE11 I had to use the window.msCrypto APIs and I
>> added
>> > a fallback if even that is not available.
>> > Currently the generated code_verifier is stored in localStorage similar
>> to
>> > the 'kc-callback-...' values.
>> > I think that localStorage is not the best place to store a temporary
>> secret
>> > ... I'm open to alternatives.
>> >
>> > The PKCE code_verifier is generated and stored in localStorage when
>> > building the auth URL, where either
>> > the plain value or an url-safe base64 encoded sha256 has of the
>> > code_verifier is used as the code_challenge, depending on the chosen
>> method.
>> > Instead of localStorage one could probably also just use sessionStorage,
>> > which would have the advantage of automatic deletion when the tab /
>> browser
>> > is closed.
>> >
>> > The two included libraries could be embedded / scoped into the keycloak
>> JS
>> > scope to not interfere with other included versions of the libraries.
>> >
>> > Cheers,
>> > Thomas
>> >
>> > On Thu, May 31, 2018 at 1:09 PM Thomas Darimont <
>> > thomas.darimont at googlemail.com> wrote:
>> >
>> >> Hi folks,
>> >>
>> >> I've got a working PoC for PKCE support in the Keycloak JS adapter that
>> >> supports `plain` and `S256` code_challenge_methods.
>> >> Works very well with Keycloak 4.0.0.beta3 and Keycloak 3.4.3.Final.
>> >> Perhaps this could serve as a base for a real PR.
>> >>
>> >> I needed to use two small js libraries to have proper support for
>> sha256
>> >> and base64 encoding for Unit8Arrays in order to
>> >> produce a codeChallenge in the same way the Keycloak server does it,
>> for
>> >> details see commit.
>> >>
>> >> Branch:
>> >>
>> https://github.com/thomasdarimont/keycloak/tree/poc/keycloak-js-pkce-support
>> >> Commit:
>> >>
>> https://github.com/thomasdarimont/keycloak/commit/f05066d430f6504246f7e518a124aef2ef5195b8
>> >>
>> >> Looks like this would solve the issue
>> >> https://issues.jboss.org/browse/KEYCLOAK-1033 (which would probably
>> need
>> >> to be renamed).
>> >>
>> >> Cheers,
>> >> Thomas
>> >>
>> >> On Wed, May 30, 2018 at 11:57 PM Thomas Darimont <
>> >> thomas.darimont at googlemail.com> wrote:
>> >>
>> >>> 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
>> >>>>>
>> >>>>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>

More information about the keycloak-dev mailing list