Oidc-client-js: Support code flow (with pkce)

Created on 12 May 2018 · 10Comments · Source: IdentityModel/oidc-client-js

The OIDC spec seems seems to allow obtaining an authorization code in addition to the ID token and access token in the same request, using the "code id_token token" response_type.
On a app with a browser-side and a server-side, this authorization code might be useful on the server-side to obtain a refresh token for "offline" operations.
However, oidc-client doesn't seem to expose this on the user information. Namely, the
SignInResponse class doesn't seem to use the code parameter.

Is there any reason for this lack of support (e.g. avoid security issues)?
Does it make sense to add it? If so, I would be grad to try to make a PR for it.

Thanks,
Pedro

enhancement

Source

pmhsfelix

👍1

Most helpful comment

code flow (with pkce) has now been implemented on the dev branch and released as a 1.6.0-beta.1.

brockallen on 10 Dec 2018

❤9 🎉6

All 10 comments

No particular reason, other than I was just focusing on the implicit scenario. I could see that scenario where the access token is used to securely deliver the code to a server side where it can do the exchange for refresh token and possibly another access token.

One thing I think about is that the spec does say that a refresh token should only issue new access tokens with the same or fewer scopes. So this would not really be a technique to get your server side a higher privileged access token. For that I'd assume you would need an extension grant or a token server that knows how to make the initial access token have fewer scopes than the user consented, but the access token obtained via the token endpoint have the rest of the scopes.

So speaking of extension grants, this leads me to the way I'd normally work around the lack of code support now in oidc-client -- if you wanted the server side to have that sort of feature, then I'd just use an extension grant based on the access token the client sends to the server, thus eliminating the need for an authorization code in the first place... I guess unless you wanted the offline_access semantic... but an extension grant could achieve the same thing anyway.

Thoughts?

brockallen on 12 May 2018

Yes, I was looking for the offline_access semantics, where the server-side component of the client app gets a long-term refresh token. I'm not looking for extended scopes, just for an extended timeframe.

From a security standpoint, it seems that using the code flow for obtaining this long-term refresh token is preferable, since it requires client app authentication (server side) when exchanging the code for the refresh token.
On the other hand, we could also have an extension grant that uses the original "implicit" token and also requires client authentication, however it seems more "ad hoc".
Makes sense?

pmhsfelix on 14 May 2018

Given some more thinking, I think I'm willing to seriously consider supporting code flow here. We'd also need PKCE support. I don't think it'd be that big of an effort to do the protocol level. The larger bit of work would be enhancing the UserManager to handle the different protocol flows to manage token lifetime.

Ping me on skype sometime if you want to chat further.

brockallen on 17 May 2018

👍9

Hi @brockallen ,

Great job on the project.

Would be great if you could add authorization code workflow support to aide native electron apps. I see that it has been marked for 1.6.0. I am just trying to figure out if I should wait or use oidc-client-js for implicit and AppAuth-JS for code workflow. Do you have an ETA for 1.6.0 alpha/beta? I am more than happy to help.

Regards