I just upgraded to version 3.1 and i'm getting an error.
I'm not sure if this is applicable, but my site is configured to hit the domain, realize its insecure, then redirect to the login. (auto login)
In app.component.ts I've got this:
let self = this;
this.oauthService.configure(authConfig);
this.oauthService.setStorage(localStorage);
this.oauthService.tokenValidationHandler = new JwksValidationHandler();
this.oauthService.loadDiscoveryDocumentAndLogin().then((res) => {
self.oauthService.setupAutomaticSilentRefresh();
});
So, my request hits the domain name, heads off to identity server and comes back with the id_token hash then throws this error:
validating access_token failed. wrong state/nonce. null yey1KhuQ9ewceuY7Qpbic4sWg5UAt8BJ6YYNryuY
When i debugged through this, I noticed that the nonce was saved, then on the second trip, the nonce wasnt in the local storage any more. So the comparison is between a valid nonce and null.
I tried creating login options with disableOAuth2StateCheck, but that just kicked the can down the road a bit. I got the error
Error validating tokens Wrong nonce: 3BAgeBU3kWkX5EiDKFDaGThnWj6pYqmsAXpf2HSO
Here is the code I have now:
this.oauthService.configure(authConfig);
this.oauthService.setStorage(localStorage);
this.oauthService.tokenValidationHandler = new JwksValidationHandler();
let loginOptions = new LoginOptions();
loginOptions.disableOAuth2StateCheck = true;
this.oauthService.loadDiscoveryDocumentAndLogin(loginOptions).then((res) => {
if (res)
self.oauthService.setupAutomaticSilentRefresh();
});
EDIT:
I was able to work around this error by using the disable state check as shown above and commenting out the other state check in node_modules/angular-oauth2-oidc/angular-oauth2-oidc.umd.js. Lines 1702 - 1706.
What would the fix be?
I am having the same error and behavior but while using trylogin/initImplicitflow calls. I am also interested in what the fix would be.
Thanks
I have the same error but cannot reproduce it consistently. I tried creating a custom storage to log every read, write and remove from the localStorage but i cannot seem to find the exact moment when the nonce is removed on the second round trip to the login page. Most of the time everything works fine, then some times it fails with an invalid nonce in state error.
Resolution of this issue, at least for us. It turns out that our server had the redirects deleted. When people used the HTTP address they were not redirected to the HTTPS address before starting the authentication process. The authentication process would start in HTTP and save the NONCE in the corresponding local/session storage. The redirect url parameter used was always HTTPS so upon authentication the user was redirected to the HTTPS address and would not find the NONCE in storage.
Once we corrected the server redirect to HTTPS://www.somesite.com/ our NONCE issue disappears as we found it in local storage.
I have the same issue attempting to use tryLogin(). In my case the auth server does not return an id_token in the redirect url, just access_token and expires_in query string parameters (its an older implementation that does not support OIDC and all the login params need to be passed to the login URL. So in my case there would be no nonce. is there a way that the library can be configured to handle this scenario?
Thanks
Same issue here, v3.1.4. and I'm not sure why I am not get my nonce and token into session storage when going through login page/redirect.
Using
oauthService.loadDiscoveryDocumentAndTryLogin()
.then(result => {
if (!oauthService.hasValidAccessToken()) {
oauthService.initImplicitFlow();
}
});
oauthService.events.filter(e => e.type === "token_received").subscribe(e => {
if (oauthService.hasValidAccessToken())
oauthService.loadUserProfile().then(userProfile => {
this.userProfileLoadedEvent.emit(userProfile);
});
});
Can replicate everytime in following 2 cases:
In this case in chrome, edge, FF, opera, they all happily login and load app straight away.
But if ...
'validating access_token failed. wrong state/nonce. null'
nonce and token are not written to sessionStorage.
The url in chrome from redirect is:
http://localhost:4200/#access_token=eyJraWQiOiJjeUZt...nbw&state=D4LRaiSiQSob9wJKpiCpa1ps9GmZwMHsbPuOXG70&token_type=Bearer&expires_in=3600
My stays in the loading state as doesn't think has valid token which is right as not in session. I then make the browser address bar url http://localhost:4200 and hit enter and it again goes passed cognito token validation and loads my app straight away getting nonce and token in session.
If I change browser address url to http://localhost:4200/# instead and hit enter when loading failed, it stays in the loading state cause the nonce and token is missing from the session.
Any ideas? For me not using https. and redirect is not https.
Decided to have a quick look at catching the code (I didn't original write this on my app) and this is what I found, change to include catch and handle err locally:
oauthService.loadDiscoveryDocumentAndTryLogin()
.catch(err => {console.error(err);})
.then(result => {
if (!oauthService.hasValidAccessToken()) {
oauthService.initImplicitFlow();
}
});
And it skips my global error handler and no longer gets stuck loading. So found problem have to now figure out how to or if need to handle error ...
I'm having the same issue with tryLogin() and using initImplicitFlow(). I get an uncaught in promise error when calling tryLogin().
I also get the "validating access_token failed. wrong state/nonce" error.
Do previous versions work when trying to call those 2 functions or has anyone found a fix for this issue? Thanks in advance!
any news?
Only seeing this in IE not in Chrome.
it happen to me at chrome
Did a quick test and changed storage to local storage instead of session storage.
this.oauthService.setStorage(localStorage);
This seems to solve the problem in IE indicating that there is something related to sessionStorage in IE that is my issue.
look like it solve my problem also :)
any security issue switch to local storage ?
The lifetime of sessionStorage is normally shorter than localStorage and might therefore be considered the better option of the two. However, the lifetime of your token might invalidate that argument.
https://www.w3.org/TR/webstorage/#the-sessionstorage-attribute
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
using the localStorage in combination with using the built in interceptor will not work as of issue #255
I've seen sth like this before. It was a race condition. Can you please provide an minimal stackblitz.com example for this?
I am using this library and silent refreshes are giving me the error as validating access_token failed. wrong state/nonce. I have set up oidc to use local storage. Any help would be great.
here is an example we used to get around this by manually calling silent refresh:
Observable.interval(this.SILENT_REFRESH_INTERVAL)
.subscribe(s => {
this.oauthService
.silentRefresh()
.then(info => {
console.log('success refresh'
})
.catch(err => console.error('token refresh error', err));
});
hope it helps anyone
Same Issue for me in chrome
Tried switching to localstorage and it worked as @gridpatrik mentioned ! Any work around to make it work with sessionstorage.
@dylandechant i tried your approach and does not seem to work.
@manfredsteyer Any update ?
We were running into the same issue, and I think I've tracked down a repro. It's quite reliable on my machine, but it does seem to be a timing issue or race condition, so the repro doesn't always immediately work.
To reproduce:
ng serve for this branch in my sample repong to reload all windowsng to reload all windowsRinse and repeat step 7/8 until the issue arises, clearly visible in the dev tools console.
invalid_nonce_in_state, 1 of them runs just fineTruth be told, this is a very artificial repro, but it is the most _reliable_ one I could make. Various posters above also mention the issue, and I myself encountered a hard-to-repro version of this issue when users close Chrome, reopen it, and try to restore multiple tabs at once. I presume my artificial repro resembles the real problem well enough.
To create useful debug info, I am logging all OAuthEvent events and also console.log(...)ing all StorageEvents where the key is 'nonce'.
Here's a screenshot of a window that went bad, and the one that loaded just fine, side by side (other 2 windows that went bad not shown):

Here's a rather large animated gif that shows this in full effect (when my mouse goes off-screen I go to VSCode to save a file and trigger ng's hot-reloading):

I speculate that the issue arises because the nonce state check will validateNonceForAccessToken against the this._storage.getItem('nonce') which might've been changed in the mean time by another window/tab in the same browser.
I don't think the browser or type of storage are the _root_ cause of this issue. It is quite possible though that they affect the issue, as they might have different kinds of multi-threading, e.g. deciding to give larger chunks of CPU time to one tab at a time, hiding the actual issue.
Not really a clue. Perhaps the this._storage.getItem('nonce') call should be done earlier on and passed to the validateNonceForAccessToken(...) call instead?
In my sample repository, the master branch does have the errors, but that doesn't seem to hurt too much, because:
tryLogin(...) call that fails, and I chain a call to a silentRefresh(...) right after that, which logs the user in (after a small delay) after allStorageEvents around access_token to change the logged in state (so other tabs that successfully log in communicate this effectively to their peers)But then again, it's merely a _sample_ repository, not really battle-tested. But perhaps it helps someone.
For what it's worth, here's a shortened version of my current login flow:
this.oauthService.loadDiscoveryDocument()
.then(() => this.oauthService.tryLogin())
.then(() => {
if (this.oauthService.hasValidAccessToken()) { return Promise.resolve(); }
return this.oauthService.silentRefresh()
.then(() => Promise.resolve())
.catch(result => {
const errorResponsesRequiringUserInteraction = [
'interaction_required',
'login_required',
'account_selection_required',
'consent_required',
];
if (result && result.reason && errorResponsesRequiringUserInteraction.indexOf(result.reason.error) >= 0) {
console.warn('User interaction is needed to log in, we will wait for the user to manually log in.');
// Could also call this.oauthService.initImplicitFlow() here...
return Promise.resolve();
}
return Promise.reject(result);
});
})
.then(() => this.isDoneLoadingSubject$.next(true))
.catch(() => this.isDoneLoadingSubject$.next(true));
window.addEventListener('storage', (event) => {
if (event.key === 'access_token' || event.key === null) {
console.warn('Noticed changes to access_token (most likely from another tab), updating isAuthenticated');
this.isAuthenticatedSubject$.next(this.oauthService.hasValidAccessToken());
}
});
this.oauthService.events
.subscribe(_ => {
this.isAuthenticatedSubject$.next(this.oauthService.hasValidAccessToken());
});
this.oauthService.events
.pipe(filter(e => ['token_received'].includes(e.type)))
.subscribe(e => this.oauthService.loadUserProfile());
this.oauthService.events
.pipe(filter(e => ['session_terminated', 'session_error'].includes(e.type)))
.subscribe(e => this.navigateToLoginPage());
this.oauthService.setupAutomaticSilentRefresh();
private isAuthenticatedSubject$ = new BehaviorSubject<boolean>(false);
public isAuthenticated$ = this.isAuthenticatedSubject$.asObservable();
private isDoneLoadingSubject$ = new ReplaySubject<boolean>();
public isDoneLoading$ = this.isDoneLoadingSubject$.asObservable();
public canActivateProtectedRoutes$: Observable<boolean> = combineLatest(
this.isAuthenticated$,
this.isDoneLoading$
).pipe(map(values => values.every(b => b)));
was this actually resolved? I feel like I see these errors quite frequently... except for me there doesnt seem to be any rhyme or reason to it.
@ronnyek The issue was (I _think_) closed at the time because there was no reliable repro. The only repro after that AFAICT is my post above yours, which also contains the resolution I currently use.
If you still have errors, I suggest reading through my comment (I know, wall of text, but hey...) and trying out the workaround there. If you still experience issues after that, try to make a minimal reproducible example (e.g. on StackBlitz) and open a new issue for it, referencing this one.
This seems to be Edge issue. See here from more info,
https://github.com/AzureAD/azure-activedirectory-library-for-js/wiki/Known-issues-on-Edge
@dylandechant Hi, I am stuck while implementing silent-refresh, I am not able to do this.
Would you please assist silent-refresh.
HTTP vs. HTTPS
I had this issue as well and was able to solve it.
The problem I had was that the frontend accepted http-requests the redirect on the other side pushed the user to the https-adress. So initImplicitFlow pushed the nonce (in my case) to the local storage but when it came back the local storage was empty (different url).
Changed the frontend to run https only. Everything is fine now.
Check that out. It may be the cause for some of you.
@manfredsteyer maybe a good approach to output console warning when initImplicitFlow is called when location.host != redirectUri.host. That would leed to the issue behavior everytime, doesn麓t it?
For anyone coming across this, I just figured out I accidentally called setupAutomaticSilentRenew twice, which caused the race condition on the first of the two renewal requests to fail due to the mentioned 'race condition'.
And since I don't see any obvious use cases for calling it twice, maybe the second call to this function should be no-op? Or maybe throw 'already setup' error?
Most helpful comment
We were running into the same issue, and I think I've tracked down a repro. It's quite reliable on my machine, but it does seem to be a timing issue or race condition, so the repro doesn't always immediately work.
Repro
To reproduce:
ng servefor this branch in my sample repongto reload all windowsngto reload all windowsRinse and repeat step 7/8 until the issue arises, clearly visible in the dev tools console.
invalid_nonce_in_state, 1 of them runs just fineTruth be told, this is a very artificial repro, but it is the most _reliable_ one I could make. Various posters above also mention the issue, and I myself encountered a hard-to-repro version of this issue when users close Chrome, reopen it, and try to restore multiple tabs at once. I presume my artificial repro resembles the real problem well enough.
Debug info
To create useful debug info, I am logging all OAuthEvent events and also
console.log(...)ing allStorageEvents where thekeyis'nonce'.Here's a screenshot of a window that went bad, and the one that loaded just fine, side by side (other 2 windows that went bad not shown):
Here's a rather large animated gif that shows this in full effect (when my mouse goes off-screen I go to VSCode to save a file and trigger
ng's hot-reloading):Hypothesis
I speculate that the issue arises because the nonce state check will
validateNonceForAccessTokenagainst thethis._storage.getItem('nonce')which might've been changed in the mean time by another window/tab in the same browser.I don't think the browser or type of storage are the _root_ cause of this issue. It is quite possible though that they affect the issue, as they might have different kinds of multi-threading, e.g. deciding to give larger chunks of CPU time to one tab at a time, hiding the actual issue.
Solution
Not really a clue. Perhaps the
this._storage.getItem('nonce')call should be done earlier on and passed to thevalidateNonceForAccessToken(...)call instead?Workarounds
In my sample repository, the
masterbranch does have the errors, but that doesn't seem to hurt too much, because:tryLogin(...)call that fails, and I chain a call to asilentRefresh(...)right after that, which logs the user in (after a small delay) after allStorageEvents aroundaccess_tokento change the logged in state (so other tabs that successfully log in communicate this effectively to their peers)But then again, it's merely a _sample_ repository, not really battle-tested. But perhaps it helps someone.
For what it's worth, here's a shortened version of my current login flow: