Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Processing tokens with a custom OIDC OP fails because the refresh_token does not contain a "." #12881

Closed
tetchel opened this issue Mar 14, 2019 · 3 comments

Comments

@tetchel
Copy link

tetchel commented Mar 14, 2019

Description

We are trying to install Che on IBM Cloud Private, which runs an IBM Liberty server as its OIDC OP.

We've made it to the access token response step (with some trouble!). The request succeeds, and the server gives us a good response, containing:

  • access_token
  • expires_in
  • id_token
  • refresh_token
  • scope
  • token_type

But then we get this error in the browser JS console (ignore the line numbers, I link the correct ones below):

Uncaught TypeError: Cannot read property 'replace' of undefined
    at decodeToken (OIDCKeycloak.js:890)
    at setToken (OIDCKeycloak.js:836)
    at authSuccess (OIDCKeycloak.js:651)
    at XMLHttpRequest.req.onreadystatechange (OIDCKeycloak.js:604)

The error is here because the refresh_token does not contain a "." so the split returns an array of size 1.
That function call is coming from here.

It looks like the Che front-end code expects the refresh_token to match a specific format, similar to the id_token (period-delimited base64 encoded data) which is not specified in the relevant RFC. All the RFC specifies (here and here) is that the refresh_token must be composed of ASCII characters on the range [0x20, 0x7E]. It is not required to encode any information the way the id_token is, so Liberty does not do this.

I suspect this is a keycloak-ism to encode the nonce and expiry into the refresh_token and then store those in refreshTokenParsed.

If I am understanding everything correctly, there should be no call to decode the refresh_token if the OP is something other than keycloak, because the token will not be in any particular format.

@tetchel
Copy link
Author

tetchel commented Mar 14, 2019

Looks like the access_token will have the same problem. It has the same definition as the refresh_token in the RFC

https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/keycloak/OIDCKeycloak.js#L847

@tetchel
Copy link
Author

tetchel commented Mar 14, 2019

That entire file seems to be keycloak-specific (though I probably shouldn't be surprised, from the filename 😄).

What OPs other than Keycloak have been confirmed to work with multi-user Che?

@tetchel
Copy link
Author

tetchel commented Mar 14, 2019

OK we found 534a961

which had a lot of good info.

It sounds like there is a good amount of work to be done for che to support our OIDC provider.

We will be looking into this... thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant