Hi everyone,
I'm getting this error in Internet Explorer 11.
validating access_token failed. wrong state/nonce.
The scenario is the following:
I have setup like below:
this.oauthService.tryLogin().then(() => {
if (!this.oauthService.hasValidIdToken() || !this.oauthService.hasValidAccessToken()) {
console.log('startSigninMainWindow URL', window.location.href)
this.oauthService.initImplicitFlow(window.location.href);
}
});
When I'm not logged in and try to go to http://localhost:4200/somecrazyroute?abc=123. It checks that I'm not logged in, send me to the IdP with "http://localhost:4200/somecrazyroute?abc=123" in the state.
After logon, it correctly send me back to http://localhost:4200/somecrazyroute?abc=123.
Except in Internet Explorer 11!
I know the problem is when I have query parameters like ?abc=123. If I remove it, it works.
All right. I was able to reproduce the issue in the demo application of this repo.
To fix it, I removed the piece of code that appends the state into the nonce:
if (state) {
state = nonce + this.config.nonceStateSeparator + state;
} else {
state = nonce;
}
After research its clear that no one knows what can and can't be stored in the state property, but, I did find something really useful here: https://auth0.com/docs/protocols/oauth2/oauth-state#how-to-use-the-parameter-to-restore-state
So basically its the app responsibility to store its state and then once you get the authentication you can redirect your user to the saved state.
I do understand for us, library consumers, having this option embedded in this library is much better than handling it by ourselves.
So to keep that as an option, I will submit the changes I did as a PR and we can discuss if its a valid option or not.
Perhaps what you reference is documented here? (Though I think it's recommended to handle event subscription slightly differently in newer versions.)
@jeroenheijmans , the code works fine in chrome. I get redirected to IdP, log in, come back to auth.html, then it redirects me to the "state" page.
But, it doesn't work the same with IE. To reproduce that, just run the demo app with the following on ngOnInit:
ngOnInit() {
this.oauthService.tryLogin().then(() => {
if (!this.oauthService.hasValidIdToken() || !this.oauthService.hasValidAccessToken()) {
this.oauthService.initImplicitFlow(window.location.href);
}
});
}
Then access your page using IE 11 like http://localhost:8080/home?test=123
You should get the same error I got in the beginning.
The PR I want to submit is to think on another way to persist that "state" url... Because looks like we shouldn't keep that along with the state (nonce).
Well, this PR (#391) changes the behaviour how additionalState works across tabs (you are using local storage), and in fact it would break our integration, so 馃憥 (maybe rather use the configured storageProvider?).
The fix for your problem would be to simply encode your state into something url safe before you pass it as a parameter to initImplicitFlow (e.g. base64url). In fact, the encoding should be done in angular-oauth2-oidc, but for some reason as you describe it does not work in the IE. This is the problem that should be fixed!
According to the spec, state is exactly there to prevent csrf and encode state to rebuild the application. What you have built, is something that has nothing todo with OIDC and should IMO not be part of this lib (especially because it is labeled unter the well known oauth2-concept (additional-)"state-parameter").
I have to confirm that this error still does exist in IE11. Does anybody have a solution for this?
It works flawlessly in Chrome... 馃槥

I'll answer my question myself, maybe it'll help someone.
nonce is set here: https://github.com/manfredsteyer/angular-oauth2-oidc/blob/3e4b70525738eb44f67793dfad5e0459446c5528/projects/lib/src/oauth-service.ts#L1775nonce is mystically gone here: https://github.com/manfredsteyer/angular-oauth2-oidc/blob/3e4b70525738eb44f67793dfad5e0459446c5528/projects/lib/src/oauth-service.ts#L1405OAuthStorage to localStorage - as seen here https://github.com/manfredsteyer/angular-oauth2-oidc/issues/255#issuecomment-384210345nonce:this.oauthService.loadDiscoveryDocumentAndLogin({
disableOAuth2StateCheck: true
})
This workaround is far from perfect, but now the access token is always available.
@ppozeti This issue is not solved, could you open it again?
Hello everybody, we tracked the issue down to this bug in Internet Explorer:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/110656/
The bug was fixed in later versions of IE11.
Solutions:
see this:

FYI @manfredsteyer
Hi All, I`ve also faced the same issue few days back in IE browser that when IE browser performs redirection from application URL to ADFS URL then it clears out local-storage so whenever the flow comes back to application after authentication at that time the claimed nonce is not matching with local-storage nonce and then as a result of this it gives an error as 'invalid nonce'. We spend almost 1 week on this and finally as a workaround for this issue, added one method which again set nonce in local-storage from the redirection URL in case of IE browser.
Best solution: Update that shitty IE 11 to the latest version of Internet Explorer 11! If necessary, escalate that critical issue to your big boss and tell him that your infrastructure team is doing a unbelievable bad job by letting you use rotten software! 馃槈
What if you're in my situation and are trying to use this on a public-facing site, where you can't control what version of IE11 your customers are using?
The IE11 error mentioned here only occurs in an intranet. In the Internet, all websites have the same zone.
Most helpful comment
I'll answer my question myself, maybe it'll help someone.
nonceis set here: https://github.com/manfredsteyer/angular-oauth2-oidc/blob/3e4b70525738eb44f67793dfad5e0459446c5528/projects/lib/src/oauth-service.ts#L1775nonceis mystically gone here: https://github.com/manfredsteyer/angular-oauth2-oidc/blob/3e4b70525738eb44f67793dfad5e0459446c5528/projects/lib/src/oauth-service.ts#L1405OAuthStoragetolocalStorage- as seen here https://github.com/manfredsteyer/angular-oauth2-oidc/issues/255#issuecomment-384210345nonce:This workaround is far from perfect, but now the access token is always available.
@ppozeti This issue is not solved, could you open it again?