PKCE support for public SMART app authorization code flow about client-js

[vlad-ignatov]

Yes, you can do that. You can also run npm run doc to regenerate the API docs and then see if you are satisfied with how your stuff are displayed (in /docs/typedoc).

I would also consider renaming createPKCEChallenge to something like createPKCEObject because it describes better what that function is doing.

[jmandel]

FYI we have PKCE support coming in SMARTv2, but the specification is still gearing up for a formal standards approval process. We are targeting the May ballot cycle.

[vlad-ignatov]

Looks like a potentially useful addition. I like what you've done in your fork. You can go ahead and submit a PR.

There is one thing I would recommend doing first though. You don't really need to include "crypto-js/enc-base64". Base64 is already available in adapters. You could pass env to the createPKCEChallenge function when you call it from authorize. Then use env.atob instead of Base64.stringify. Or even better - because this is for browsers only, a simple atob should work as well.

This leads me to the next questions. I assume this is working for you but I don't have a proper server to test it against. I was wondering about few other things:

1. Do we have to support plain mode, even if we are sha256-capable?
2. Do we have to supportPKCE on the server, even though a back-end app can use a clientSecret instead?

I would say NO to both of these as they are not likely to happen in real life, but I would like to hear your opinion too.

[t-zhao]

Hey Vlad
Thanks for the info, I will change the base64 part.

For the 2 questions

1. No. Auth server who support pkce should support sha256. (Our vender don't even support plain)
2. No. Not from a server, could be native app which probably won't use this lib.

Question for submitting the PR, I already re-gen the /dist folder, but not the /docs folder. Do I need to re-gen both of them?

[t-zhao]

Hey @vlad-ignatov, after some investigation of using btoa to do Base64 Encoding. I think if we still going to use crypto-js for SHA256, it is better to use the Base64 from crypto-js since they use the same data format (WordArray). Otherwise we need to do WordArray => hex string => binary string which is slower and harder to maintain. Also the extra bundle size for crypto-js/enc-base64 is 4kb (crypto-core: 22kb, crypto-js/sha256: 5kb).

We also looked at options for not using crypto-js at all. It will look like

// Calculate the SHA256 hash of the input text. 
// Returns a promise that resolves to an ArrayBuffer
function sha256(plain) {
    const encoder = new TextEncoder();
    const data = encoder.encode(plain);
    return window.crypto.subtle.digest('SHA-256', data);
}

// Base64-urlencodes the input string
function base64urlencode(str) {
    // Convert the ArrayBuffer to string using Uint8 array to convert to what btoa accepts.
    // btoa accepts chars only within ascii 0-255 and base64 encodes them.
    // Then convert the base64 encoded to base64url encoded
    //   (replace + with -, replace / with _, trim trailing =)
    return btoa(String.fromCharCode.apply(null, new Uint8Array(str)))
        .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}

But window.crypto.subtle.digest is not supported by IE10 so I guess that is a no go for this client.
Thoughts?

[vlad-ignatov]

I feel like window.crypto is the way to go. That said, there are a few things to consider:

1. This project is configured to automatically polyfill the missing stuff when you build the browser bundle using core-js. I don't think that crypto is included in core-js, but I have not tried it. Have you?
2. We are going to drop IE10 support soon (when we manage to verify that there is no EHR left that is using it). According to https://caniuse.com/#search=crypto, IE 11 supports it based on older version of the spec. Have you tried that?
3. The only reason to support IE10/11 are those EHRs that are slow to upgrade. In the same time, you are the first to request this feature, saying that your OAuth2 vendor only supports public application Authorization Code flow with PKCE support. Is there any reason that would also force you to use IE(10)? If not, we can probably do without a polyfill.
4. I am not aware of an EHR that supports/requires PKCE auth. @jmandel - do you know if such EHR exists?

[t-zhao]

@vlad-ignatov core-js doesn't have crypto-js. (FYI if we use nodejs crypto.createHash like we did in the lib.test.ts, it will browserify it with adding 700kb)
I haven't try IE11, but it will be something like here.
For our use case, our recommend browser is chrome. But we havn't drop support for IE11 as far as I know.
I still feel like using crypto-js is cleaner without any compatibility concern, and easier to test. But I could see the it is more native using window.crypto.
Thoughts?

[bradcurfman]

@vlad-ignatov @t-zhao, is there any chance this gets merged into client-js in the near future? We are building a web application that needs PKCE support as our auth provider requires auth code flow with PKCE for public clients.

[timothyakampa]

@vlad-ignatov @t-zhao Is there any chance that we can get this merged and published sometime soon?

[vlad-ignatov]

After some internal discussions we have decided not to include PKCE support for now. It is not exactly part of the SMART spec and it would be difficult for us to maintain. This might change in the future if more than a few users are interested in having this feature. Please use your fork for now and we will let you know if things change and we decide to support this.