I have an angular 6 project where I use the latest oidc-client ([email protected], [email protected]).
During dev-builds everything works as expected, but when I make a production build by ng build --prod, the method UserManager.signinRedirectCallback() (which gets called right after the authentication server redirected to the app's auth-callback) throws the error "Failed to parse id_token".
Has anybody experienced the same error? I did not change anything on my code, but updating oidc-client to v1.5.1 (from 1.5.0).
When i revert oidc-client back to 1.5.0, everythings works as expected again (also in production builds).
I will try to prepare a StackBlitz for monday, but I don't know if the error will show up, since it occurs in production builds only...
Can you paste in your id_token for us?
The same error here when updating from angular 5 to [email protected] ( i'm using [email protected])
Here's my decoded id_token: (using jwt.io)
HEADER:ALGORITHM & TOKEN TYPE
{
"alg": "RS256",
"kid": "--hidden--",
"typ": "JWT"
}
PAYLOAD:DATA
{
"nbf": 1528706698,
"exp": 1528707418,
"iss": "--hidden--",
"aud": "--hidden--",
"nonce": "7089560554cd46d59aab25d27f84245b",
"iat": 1528706698,
"at_hash": "sWzGONS0IBRsrzhn2kGtIw",
"sid": "8ae3c2d37f1ef62cd437d32401f1a09b",
"sub": "--hidden--",
"auth_time": 1528706698,
"idp": "local",
"amr": [
"pwd"
]
}
Sorry, I also should have asked for the client-side logs. That might help where in the workflow it's failing to parse the id_token.
Also, if the only thing that changed was a version of angular then it makes me wonder if somehow the id_token is being truncated in some way during the response processing (perhaps while trying to read the value from the URL/hash fragment).
Also I have the same problem with the version oidc-client 1.5.1 and angular 6. In one SPA where the URL is shorter is working also with 1.5.1 and in one with longer url and /de or /en on end is not working with 1.5.1 but is working with 1.5.0.
I have same issue
My client-side error-logs:
ResponseValidator._validateIdToken: Failed to parse id_token
{…}
header: null
payload: null
__proto__: Object { … }
Error: Failed to parse id_token
Stack trace:
3Rfw/e.exports_validateIdToken@http://my.internal.url/main.f5e30e257df08d940baa.js:1:71847
3Rfw/e.exports_validateIdTokenAndAccessToken@http://my.internal.url/main.f5e30e257df08d940baa.js:1:71407
3Rfw/e.exports_validateTokens@http://my.internal.url/main.f5e30e257df08d940baa.js:1:71095
3Rfw/e.exportshttp://my.internal.url/main.f5e30e257df08d940baa.js:1:66780
0TWp/invoke@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:8059
onInvoke@http://my.internal.url/main.f5e30e257df08d940baa.js:1:332799
0TWp/invoke@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:7986
0TWp/run@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:3219
D/<@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:14483
0TWp/invokeTask@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:8734
onInvokeTask@http://my.internal.url/main.f5e30e257df08d940baa.js:1:332711
0TWp/invokeTask@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:8647
0TWp/runTask@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:3910
d@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:10963
0TWp/invokeTask@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:9864
m@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:20756
b@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:20988
...this refers to the method [email protected]:11924:
JoseUtil.parseJwt = function parseJwt(jwt) {
_Log.Log.debug("JoseUtil.parseJwt");
try {
var token = _jsrsasign.jws.JWS.parse(jwt);
return {
header: token.headerObj,
payload: token.payloadObj
};
} catch (e) {
_Log.Log.error(e);
}
};
which is called by the method [email protected]:11686:
var jwt = this._joseUtil.parseJwt(response.id_token);
if (!jwt || !jwt.header || !jwt.payload) {
_Log.Log.error("ResponseValidator._validateIdToken: Failed to parse id_token", jwt);
return Promise.reject(new Error("Failed to parse id_token"));
}
Somewhere in the processing the token header and payload became null, so let's dig deeper:
I logged the token which is passed to the method _jsrsasign.jws.JWS.parse(jwt); and decoded it at jwt.io:
JoseUtil.parseJwt = function parseJwt(jwt) {
_Log.Log.debug("JoseUtil.parseJwt");
_Log.Log.info(jwt): // <-- token logged here
try {
var token = _jsrsasign.jws.JWS.parse(jwt);
return {
header: token.headerObj,
payload: token.payloadObj
};
} catch (e) {
_Log.Log.error(e);
}
};
Decoded token:
HEADER:ALGORITHM & TOKEN TYPE
{
"alg": "RS256",
"kid": "--hidden--",
"typ": "JWT"
}
PAYLOAD:DATA
{
"nbf": 1528795502,
"exp": 1528796222,
"iss": "--hidden--",
"aud": "--hidden--",
"nonce": "0a31733215fb44feaf5ba6de037cf182",
"iat": 1528795502,
"at_hash": "AUEkF42sPR2WOSn0KqWDpg",
"sid": "705a5fc38f40260daa5755b312585cd7",
"sub": "--hidden--",
"auth_time": 1528794979,
"idp": "local",
"amr": [
"pwd"
]
}
...looks valid. Any ideas?
Oh, I missed a log message:
UserManager.getUser: user not found in storage
This message gets logged 3 times (after my app's auth-callback gets called and right before the id_token related error messages get logged).
Here's the complete log (changed Log.level to DEBUG):
Switched to http://my.internal.url/
GET http://my.internal.url/
...some additional http GET calls...
UserManager._loadUser: no user storageString
UserManager._loadUser: no user storageString
UserManager._loadUser: no user storageString
UserManager._signinStart: got navigator window handle
OidcClient.createSigninRequest
MetadataService.getMetadataProperty for: authorization_endpoint
MetadataService.getMetadata: getting metadata from http://my.auth.server.url/auth/.well-known/openid-configuration
JsonService.getJson, url: http://my.auth.server.url/auth/.well-known/openid-configuration
UserManager.getUser: user not found in storage
UserManager.getUser: user not found in storage
UserManager.getUser: user not found in storage
XHR GET http://my.auth.server.url/auth/.well-known/openid-configuration
JsonService.getJson: HTTP response received, status 200
MetadataService.getMetadata: json received
MetadataService.getMetadataProperty: metadata recieved
OidcClient.createSigninRequest: Received authorization endpoint http://my.auth.server.url/auth/connect/authorize
SigninState.toStorageString
WebStorageStateStore.set 9a9ffe24e52344dbb910a4e659d8bdc3
UserManager._signinStart: got signin request
Switched to http://my.auth.server.url/auth/connect/authorize?client_id=hidden&redirect_uri=http%3A%2F%2Fmy.internal.url%2Fauth-callback&response_type=id_token%20token&scope=openid%20profile%20my.api&state=9a9ffe24e52344dbb910a4e659d8bdc3&nonce=86c6f5b48b5f4624a3230dc0c36c0cb4
UserManager.signinRedirect: successful
GET http://my.auth.server.url/auth/connect/authorize?client_id=hidden&redirect_uri=http%3A%2F%2Fmy.internal.url%2Fauth-callback&response_type=id_token%20token&scope=openid%20profile%20my.api&state=9a9ffe24e52344dbb910a4e659d8bdc3&nonce=86c6f5b48b5f4624a3230dc0c36c0cb4
GET http://my.auth.server.url/auth/account/login?returnUrl=%2Fauth%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Dhidden%26redirect_uri%3Dhttp%253A%252F%252Fmy.internal.url%252Fauth-callback%26response_type%3Did_token%2520token%26scope%3Dopenid%2520profile%2520my.api%26state%3D9a9ffe24e52344dbb910a4e659d8bdc3%26nonce%3D86c6f5b48b5f4624a3230dc0c36c0cb4
...some additional http GET calls...
Switched to http://my.auth.server.url/auth/Account/Login?returnurl=%2Fauth%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Dhidden%26redirect_uri%3Dhttp%253A%252F%252Fmy.internal.url%252Fauth-callback%26response_type%3Did_token%2520token%26scope%3Dopenid%2520profile%2520my.api%26state%3D9a9ffe24e52344dbb910a4e659d8bdc3%26nonce%3D86c6f5b48b5f4624a3230dc0c36c0cb4
POST http://my.auth.server.url/auth/Account/Login?returnurl=%2Fauth%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Dhidden%26redirect_uri%3Dhttp%253A%252F%252Fmy.internal.url%252Fauth-callback%26response_type%3Did_token%2520token%26scope%3Dopenid%2520profile%2520my.api%26state%3D9a9ffe24e52344dbb910a4e659d8bdc3%26nonce%3D86c6f5b48b5f4624a3230dc0c36c0cb4
GET http://my.auth.server.url/auth/connect/authorize/callback?client_id=hidden&redirect_uri=http%3A%2F%2Fmy.internal.url%2Fauth-callback&response_type=id_token%20token&scope=openid%20profile%20my.api&state=9a9ffe24e52344dbb910a4e659d8bdc3&nonce=86c6f5b48b5f4624a3230dc0c36c0cb4
GET http://my.internal.url/auth-callback#id_token=hidden&access_token=hidden&token_type=Bearer&expires_in=600&scope=openid%20profile%20my.api&state=9a9ffe24e52344dbb910a4e659d8bdc3&session_state=VTbM8RrNUxMFJe3mCHHZ6J6hs3wPmN_IAxWdPNSc86E.6974d18abbe4b4ddce3968a01cec5021
...some additional http GET calls...
UserManager._loadUser: no user storageString
UserManager._loadUser: no user storageString
UserManager._loadUser: no user storageString
UserManager.getUser: user not found in storage
UserManager.getUser: user not found in storage
UserManager.getUser: user not found in storage
OidcClient.processSigninResponse
WebStorageStateStore.remove 9a9ffe24e52344dbb910a4e659d8bdc3
SigninState.fromStorageString
OidcClient.processSigninResponse: Received state from storage; validating response
ResponseValidator.validateSigninResponse
ResponseValidator._processSigninParams: state validated
ResponseValidator.validateSigninResponse: state processed
ResponseValidator._validateTokens: Validating id_token and access_token
JoseUtil.parseJwt
ResponseValidator._validateIdToken: Failed to parse id_token
Object { header: null, payload: null }
Error: Failed to parse id_token
Stack trace:
3Rfw/e.exports_validateIdToken@http://my.internal.url/main.a9fcdd1fb67265d20798.js:1:71847
3Rfw/e.exports_validateIdTokenAndAccessToken@http://my.internal.url/main.a9fcdd1fb67265d20798.js:1:71407
3Rfw/e.exports_validateTokens@http://my.internal.url/main.a9fcdd1fb67265d20798.js:1:71095
3Rfw/e.exportshttp://my.internal.url/main.a9fcdd1fb67265d20798.js:1:66780
0TWp/invoke@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:8059
onInvoke@http://my.internal.url/main.a9fcdd1fb67265d20798.js:1:332813
0TWp/invoke@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:7986
0TWp/run@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:3219
D/<@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:14483
0TWp/invokeTask@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:8734
onInvokeTask@http://my.internal.url/main.a9fcdd1fb67265d20798.js:1:332725
0TWp/invokeTask@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:8647
0TWp/runTask@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:3910
d@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:10963
0TWp/invokeTask@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:9864
m@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:20756
b@http://my.internal.url/polyfills.d31abbb2bb1aefc761e8.js:1:20988
Have the same issue. However I am using react-js@16 webpack@4, I would guess that it is something related to the webpack uglify-js minification code is borking something.
edit: thought it might be https://github.com/IdentityModel/oidc-client-js/blob/141fa1b78d25d2e1621ed05f5363698e1c453b9f/src/Global.js#L34
minifying wrong. But looking through the bundle, it appears to minify to function(){if(!i&&"undefined"!=typeof window)return sessionStorage} which is correct...
Are you all using the ~/lib version or the ~/dist version?
ng serve --open --aot this works fine
but when ng serve --prod --open --aot used then create issue.
~/lib version.
Angular uses the minified ~/lib version (I tested this to be 100% sure).
but when ng serve --prod --open --aot used then create issue.
So what does that do differently?
Rolling back to v1.5.0 made the thing.
Had React 16 and Webpack 4
I have the same problem, I didn't change anything in my code and I'm using Angular 6.0.4, I updated from oidc-client.js version 1.5.0 to 1.5.1 and the issue appeared, when reverting back to 1.5.0 everything started to work as expected.
I am affected by the same problem.
Here is an example project which lets you reproduce the problem.
Steps to reproduce:
npm inpm run start:prod -> error when click on "Protected"npm run start -> click on "Protected" works as expectedHere's a workaround I'm using with webpack@4 and [email protected] (ie. the lib version seems to be working correctly):
{
resolve: {
alias: {
"oidc-client": resolve(__dirname, "node_modules", "oidc-client", "lib", "oidc-client.js")
}
}
}
@ljani but that means your pulling in the non-minified version. so this means there's something wonky with how minification is being done.
Hi all -- so I think isolated the issue for this and it has something to do with how I updated webpack (and so that makes me think I did it wrong). In any event, I pushed a branch that reverted the webpack change I made in 1.5.0. The branch is here:
https://github.com/IdentityModel/oidc-client-js/tree/revert_webpack_update
Mind testing by dropping it in and seeing if it's better for you? I tested with @jonek's sample and it seems to be working.
Problem still exists. How should we use this lib with angular? I have the callback and silent renew html pages which import the "min" file and then in the app code I import the classes and use them. I think that the problem is not in the "min" file but in how this lib is compiled with angular 6.
file but in how this lib is compiled with angular 6.
I don't know angular6 and its build system, so I would need from you something that helps debug this.
The thing is that with 1.5.0 is working fine. With 1.5.1 the renew interval is broken and something under the hood happens because all the calls to the services fail. With Chrome it says... "failed to fetch data", thats why the error "Failed to parse id_token" is thrown.
hmmm... ok... that helps, i think. i'll try to put out another branch with a possible fix. thanks for helping -- it's very hard to debug these things if you can't see what's happening :)
I pushed this branch:
https://github.com/IdentityModel/oidc-client-js/tree/revert_jsrsasign_pruning
So what's happening here is that 3 different things changed. I'm trying to revert each change, one by one, with these branches and have you test. This branch reverts the last couple of files I removed in 1.5.1 from the jsrsasign library which parses and validates the id_token. So your hint that it worked in 1.5.0 but not in 1.5.1 helped. Thanks and please try!
Apparently the issue dissapears but now I get the same error that was in 1.5.0 (https://github.com/IdentityModel/oidc-client-js/issues/560) regarding "Cannot execute from a freed script".
With 1.4.1 I don't have any issue.
I just tried using the branch above and it did not fix this issue for me.
4main.66a248e0744bd12d37ed.js:1 UserManager.getUser: user not found in storage
main.66a248e0744bd12d37ed.js:1 ResponseValidator._validateIdToken: Failed to parse id_token {header: null, payload: null}
e.error @ main.66a248e0744bd12d37ed.js:1
e._validateIdToken @ main.66a248e0744bd12d37ed.js:1
e._validateIdTokenAndAccessToken @ main.66a248e0744bd12d37ed.js:1
e._validateTokens @ main.66a248e0744bd12d37ed.js:1
(anonymous) @ main.66a248e0744bd12d37ed.js:1
t.invoke @ polyfills.d0b97a8dc8191f6a9174.js:1
onInvoke @ main.66a248e0744bd12d37ed.js:1
t.invoke @ polyfills.d0b97a8dc8191f6a9174.js:1
e.run @ polyfills.d0b97a8dc8191f6a9174.js:1
(anonymous) @ polyfills.d0b97a8dc8191f6a9174.js:1
t.invokeTask @ polyfills.d0b97a8dc8191f6a9174.js:1
onInvokeTask @ main.66a248e0744bd12d37ed.js:1
t.invokeTask @ polyfills.d0b97a8dc8191f6a9174.js:1
e.runTask @ polyfills.d0b97a8dc8191f6a9174.js:1
d @ polyfills.d0b97a8dc8191f6a9174.js:1
Promise.then (async)
v @ polyfills.d0b97a8dc8191f6a9174.js:1
t.scheduleTask @ polyfills.d0b97a8dc8191f6a9174.js:1
onScheduleTask @ polyfills.d0b97a8dc8191f6a9174.js:1
t.scheduleTask @ polyfills.d0b97a8dc8191f6a9174.js:1
e.scheduleTask @ polyfills.d0b97a8dc8191f6a9174.js:1
e.scheduleMicroTask @ polyfills.d0b97a8dc8191f6a9174.js:1
D @ polyfills.d0b97a8dc8191f6a9174.js:1
t.then @ polyfills.d0b97a8dc8191f6a9174.js:1
e.appInitializer @ main.66a248e0744bd12d37ed.js:1
e.runInitializers @ main.66a248e0744bd12d37ed.js:1
(anonymous) @ main.66a248e0744bd12d37ed.js:1
(anonymous) @ main.66a248e0744bd12d37ed.js:1
t.invoke @ polyfills.d0b97a8dc8191f6a9174.js:1
onInvoke @ main.66a248e0744bd12d37ed.js:1
t.invoke @ polyfills.d0b97a8dc8191f6a9174.js:1
e.run @ polyfills.d0b97a8dc8191f6a9174.js:1
e.run @ main.66a248e0744bd12d37ed.js:1
e.bootstrapModuleFactory @ main.66a248e0744bd12d37ed.js:1
zUnb @ main.66a248e0744bd12d37ed.js:1
p @ runtime.a66f828dca56eeb90e02.js:1
4 @ main.66a248e0744bd12d37ed.js:1
p @ runtime.a66f828dca56eeb90e02.js:1
n @ runtime.a66f828dca56eeb90e02.js:1
e @ runtime.a66f828dca56eeb90e02.js:1
(anonymous) @ main.66a248e0744bd12d37ed.js:1
main.66a248e0744bd12d37ed.js:1 Error: Failed to parse id_token
at e._validateIdToken (main.66a248e0744bd12d37ed.js:1)
at e._validateIdTokenAndAccessToken (main.66a248e0744bd12d37ed.js:1)
at e._validateTokens (main.66a248e0744bd12d37ed.js:1)
at main.66a248e0744bd12d37ed.js:1
at t.invoke (polyfills.d0b97a8dc8191f6a9174.js:1)
at Object.onInvoke (main.66a248e0744bd12d37ed.js:1)
at t.invoke (polyfills.d0b97a8dc8191f6a9174.js:1)
at e.run (polyfills.d0b97a8dc8191f6a9174.js:1)
at polyfills.d0b97a8dc8191f6a9174.js:1
at t.invokeTask (polyfills.d0b97a8dc8191f6a9174.js:1)
main.66a248e0744bd12d37ed.js:1 UserManager.getUser: user not found in storage
main.66a248e0744bd12d37ed.js:1 UserManager.signinRedirect: successful
It works fine when running locally, but it fails when I package it up for deployment.
I'll try to get a DEBUG log and dump it here.
It's a minification issue. I'm using Webpack 4 to instead of Webpack 3 to bundle the lib (https://github.com/IdentityModel/oidc-client-js/pull/601) and when I set
optimization: {
minimize: false
}
I get a lib of 409 Ko in size and it works.
I have to play with the different Uglify flags to see which one is the culprit.
Okay, understood. I am fully functional on version 1.4.1 using minification, so I guess I'll stay on that version until this is resolved. But the code in the revert_jsrsasign_pruning branch above does not seem to fix this issue.
@akiander do you have a super simple repo that I can use/test with?
Can someone try my PR https://github.com/IdentityModel/oidc-client-js/pull/601 please? I disabled mangling of function names, the bundle size is now 241Ko instead of 224Ko.
@brockallen - I put several hours into trying to build a simple repo that will reproduce the issue but I failed. Whenever I try to generate a small project that experiences this issue, I typically find that I just can't reproduce the issue. It only happens against my production application which is fairly large and proprietary, so not really something I can put on github.
@DavidRouyer - I tried out PR #601 and it fixes my issue. After applying that pull request locally and npm installing it, the issue I am running into is solved.
My recommendation is to go with PR #601
I really appreciate the support on this one.
Okies, I'll have a look at it then. Thanks everyone for trying to help sort this out!
Here's a minimal repro.
EDIT: Sorry, I forgot the logs:
oidc-client-js-583 >>> npm run test-ok
...
JoseUtil.parseJwt
ResponseValidator._validateIdToken: Received issuer
ResponseValidator._validateIdToken: Received signing keys
ResponseValidator._validateIdToken: Validaing JWT; using clock skew (in seconds) of: 300
ResponseValidator._validateIdToken: JWT validation successful
{ id_token:
'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImEzck1VZ01Gdjl0UGNsTGE2eUYzekFrZnF1RSIsImtpZCI6ImEzck1VZ01Gdjl0UGNsTGE2eUYzekFrZnF1RSJ9.eyJpc3MiOiJodHRwczovL2xvY2FsaG9zdDo0NDMzMy9jb3JlIiwiYXVkIjoianMudG9rZW5tYW5hZ2VyIiwiZXhwIjoxNDU5MTMwMjAxLCJuYmYiOjE0NTkxMjk5MDEsIm5vbmNlIjoiNzIyMTAwNTIwOTk3MjM4MiIsImlhdCI6MTQ1OTEyOTkwMSwiYXRfaGFzaCI6IkpnRFVDeW9hdEp5RW1HaWlXYndPaEEiLCJzaWQiOiIwYzVmMDYxZTYzOThiMWVjNmEwYmNlMmM5NDFlZTRjNSIsInN1YiI6Ijg4NDIxMTEzIiwiYXV0aF90aW1lIjoxNDU5MTI5ODk4LCJpZHAiOiJpZHNydiIsImFtciI6WyJwYXNzd29yZCJdfQ.f6S1Fdd0UQScZAFBzXwRiVsUIPQnWZLSe07kdtjANRZDZXf5A7yDtxOftgCx5W0ONQcDFVpLGPgTdhp7agZkPpCFutzmwr0Rr9G7E7mUN4xcIgAABhmRDfzDayFBEu6VM8wEWTChezSWtx2xG_2zmVJxxmNV0jvkaz0bu7iin-C_UZg6T-aI9FZDoKRGXZP9gF65FQ5pQ4bCYQxhKcvjjUfs0xSHGboL7waN6RfDpO4vvVR1Kz-PQhIRyFAJYRuoH4PdMczHYtFCb-k94r-7TxEU0vp61ww4WntbPvVWwUbCUgsEtmDzAZT-NEJVhWztNk1ip9wDPXzZ2hEhDAPJ7A',
profile:
{ iss: 'https://localhost:44333/core',
aud: 'js.tokenmanager',
exp: 1459130201,
nbf: 1459129901,
nonce: '7221005209972382',
iat: 1459129901,
at_hash: 'JgDUCyoatJyEmGiiWbwOhA',
sid: '0c5f061e6398b1ec6a0bce2c941ee4c5',
sub: '88421113',
auth_time: 1459129898,
idp: 'idsrv',
amr: [ 'password' ] } }
oidc-client-js-583 >>> npm run test-fail
...
JoseUtil.parseJwt
ResponseValidator._validateIdToken: Failed to parse id_token { header: null, payload: null }
Error: Failed to parse id_token
at t._validateIdToken (C:\oidc-client-js-583\dist\main.js:3:21713)
at Object.<anonymous> (C:\oidc-client-js-583\dist\main.js:42:57290)
at r (C:\oidc-client-js-583\dist\main.js:1:172)
at C:\oidc-client-js-583\dist\main.js:1:964
at Object.<anonymous> (C:\oidc-client-js-583\dist\main.js:1:973)
at Module._compile (internal/modules/cjs/loader.js:702:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:713:10)
at Module.load (internal/modules/cjs/loader.js:612:32)
at tryModuleLoad (internal/modules/cjs/loader.js:551:12)
at Function.Module._load (internal/modules/cjs/loader.js:543:3)
Same problem here. Not an angular or react app.
Webpack 4.11.1/webpack-cli 3.0.3
Typescript 2.9.1
oidc-client 1.5.1
I've simply got oidc-client listed as a dependency in package.json.
And in typescript I require OidcClient like this:
import { UserManager, Log, User, WebStorageStateStore } from "oidc-client";
Dev webpack build works just fine.
I am successfully logging in to the ID Server and getting redirected to the client login call back. But production webpack build produces: ResponseValidator._validateIdToken: Failed to parse id_token {header: null, payload: null} from within the client login callback -- when signinPopupCallback is called.
I should also mention that logout seems broken too. Most likely due to the client not receiving a token.
Are you guys using self signed ssl certs for you https://
endpoint where you are deploying the minified build?
@cosmoKenney does @DavidRouyer's PR fix your problem?
I put out a 1.5.2-beta.1 that contains this fix. Please have a look! Thanks everyone for helping me out on this. I'm a security person, not a cutting edge front-end JS person. :/
@brockallen Confirmed fixed. Thanks so much! This app is now in the hands of my QA department.
I can also confirm that 1.5.2-beta.1 fixes the issue.
Great work!
I have the same Issue with Angular 6 and the newest oidc-client Version 1.5.4
It only works with Version 1.5.0.
From 1.5.1 it does not work anymore.
I work with 1.5.2 and angular 6 and is working fine
ResponseValidator.prototype._validateIdToken::_validateIdToken this._joseUtil.parseJwt
Exception: TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them at Function.remoteFunction (
Most helpful comment
I put out a 1.5.2-beta.1 that contains this fix. Please have a look! Thanks everyone for helping me out on this. I'm a security person, not a cutting edge front-end JS person. :/