Skip to content

[Question]: Nonce is not generated for silentRefresh #2068

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

Open
Leon2209 opened this issue Jan 20, 2025 · 0 comments
Open

[Question]: Nonce is not generated for silentRefresh #2068

Leon2209 opened this issue Jan 20, 2025 · 0 comments
Labels

Comments

@Leon2209
Copy link

Leon2209 commented Jan 20, 2025

What Version of the library are you using?
18.0.2
code workflow

Question
Hey, we were investigating a problem in our application where the silent refresh isn't working due to a nonce check. We came across various issues where the suggested solution was to deactivate the nonce check using:

ignoreNonceAfterRefresh: true,

However, we were not comfortable with disabling this check and decided to investigate why this issue was occurring. During our investigation, we found the following lines of code in the silent refresh functionality:

RefreshSessionCallbackHandlerService.ts

static { this.refreshTokenNoncePlaceholder = '--RefreshToken--';}

// Nonce is not used with refresh tokens; but Key cloak may send it anyway
this.flowsDataService.setNonce(TokenValidationService.refreshTokenNoncePlaceholder, config);

Our understanding is that every time the silent refresh runs, it sends this placeholder as the nonce instead of generating a new one or the inital one. When the response is received, the system checks for the nonce from the request against this placeholder string. This check fails because it seems like our SSO server does not accept the string from refreshTokenNoncePlaceholder and instead returns the nonce which was used for authenfication in the first place.

I managed to inject my initial nonce, which was generated before, into a silent renewal request and the nonce check worked as expected.

I'm not deeply familiar with how the OIDC and OAuth workflows work, but from my understanding, this could also be a potential attack vector.
Apologies if I am missing something in the authentication workflow.

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

No branches or pull requests

1 participant