[ELY-2903] skip nonce check on oidc client refresh. Check nonce on oi…#2277
[ELY-2903] skip nonce check on oidc client refresh. Check nonce on oi…#2277rsearls wants to merge 1 commit intowildfly-security:2.xfrom
Conversation
| try { | ||
| TokenValidator tokenValidator = TokenValidator.builder(clientConfiguration).build(); | ||
| TokenValidator.VerifiedTokens verifiedTokens = tokenValidator.parseAndVerifyToken(idTokenString, accessTokenString, cookie); | ||
| TokenValidator.VerifiedTokens verifiedTokens = tokenValidator.parseAndVerifyToken(idTokenString, accessTokenString, cookie, false); |
There was a problem hiding this comment.
With the approach I mentioned below, we could leave this unchanged (and the nonce won't get validated).
|
@rsearls Just to check, were you able to reproduce the issue with Keycloak? |
504e217 to
ddcdf0e
Compare
| } | ||
|
|
||
| public VerifiedTokens parseAndVerifyToken(final String idToken, final String accessToken, | ||
| OidcHttpFacade.Cookie cookie) throws OidcException { |
There was a problem hiding this comment.
Just realized, I guess the cookie is something that is specifically used for the nonce validation case, right? So perhaps there's some more cleanup that would be good to do so this method would just need to take the idToken and accessToken.
Looking back at the original PR, RefreshableOidcSecurityContext was updated so that it was possible to pass it the session random value cookie but that's no longer needed now.
ddcdf0e to
f1167c9
Compare
| } | ||
|
|
||
| public VerifiedTokens parseAndVerifyToken(final String idToken, final String accessToken, | ||
| OidcHttpFacade.Cookie cookie) throws OidcException { |
f1167c9 to
0157e01
Compare
|
test case pushded |
0157e01 to
71fa1b4
Compare
| private static final int ACCESS_TOKEN_LIFESPAN = 120; | ||
| private static final int SESSION_MAX_LIFESPAN = 120; | ||
| private static final int REFRESH_ACCESS_TOKEN_LIFESPAN = 10; | ||
| private static final int REFRESH_SESSION_MAX_LIFESPAN = 10; |
There was a problem hiding this comment.
Just curious, is there a reason these low numbers are needed here if we are forcing the refresh to happen regardless?
There was a problem hiding this comment.
Git CI was failing on every test platform due to time over run for this test.
With a lifespan of 120. testRefreshToken was taking 35sec to run and all the
tests in the file 2+mins. Reducing the lifespan for this test enabled the test file
to run in about 1.5 min.
There was a problem hiding this comment.
Do we know what was causing the test to take longer to run in that case? Because we're calling refreshToken with checkActive set to false, I'm just wondering why changing the access token lifespan would impact the test duration.
There was a problem hiding this comment.
I tried using a lifespan of 120 locally but I don't seem to see a significant difference in the overall time the test takes to run compared to when the lifespan is set to 10.
There was a problem hiding this comment.
I think we could try setting the lifespan back to 120 and see if the CI issue occurs. If it does, we can then take a closer look to see what's happening. I can't think of why the token lifespan would be affecting the test duration here.
There was a problem hiding this comment.
another job has failed.
https://github.com/wildfly-security/wildfly-elytron/actions/runs/14781730898
This job just failed with 1 Bind Address already in use: NET_Bind (window-11)
All other jogs canceled (I'm assuming because none responsive)
I have restarted the job.
There was a problem hiding this comment.
Thanks, Rebecca. Yes, I see the bind address in use message in the tests. Thanks for re-triggering. We should create an ELY issue for this intermittent bind address problem on Windows. Looks like the tests that I've seen fail with this intermitent issue are ElytronAuthenticatorTest, MaskedPasswordSaslAuthenticationTest, JwtSecurityRealmTest, OAuth2SaslClientV10Test, and OAuth2SaslClientV11Test.
There was a problem hiding this comment.
I don't see this as an elytron issue. It's an issue with the github CI env. We see this type of failure in the middle of the (U.S.) day not in the morning or evening. Most likely the system is under heavy load at that time which causes communication delays. Perhaps we should discuss this with the github CI maintenance team first.
There was a problem hiding this comment.
I'm wondering if it could be related to something happening in a previous test where something doesn't get stopped/cleaned up in time before these tests start or something like that.
There was a problem hiding this comment.
This is always a possibility. Most likely it would be very hard to find as the failures are random and not reproducable locally. Perhaps asking the performance team to evaluate elytron.
| " \"" + REALM + "\" : \"" + TEST_REFRESH_REALM + "\",\n" + | ||
| " \"" + RESOURCE + "\" : \"" + CLIENT_ID + "\",\n" + | ||
| " \"" + PUBLIC_CLIENT + "\" : \"false\",\n" + | ||
| " \"" + AUTH_SERVER_URL + "\" : \"" + authServerUrl + "\",\n" + |
There was a problem hiding this comment.
It would be good to use the client-id, provider-url configuration instead in this config.
| } | ||
|
|
||
| public RefreshableOidcSecurityContext(OidcClientConfiguration clientConfiguration, OidcHttpFacade.Cookie cookie, OidcTokenStore tokenStore, String tokenString, | ||
| public RefreshableOidcSecurityContext(OidcClientConfiguration clientConfiguration, OidcTokenStore tokenStore, String tokenString, |
There was a problem hiding this comment.
Just an FYI for other reviewers, this isn't public API.
|
Requested changes complete |
| OidcAccount account = (OidcAccount) session.getAttachment(OidcAccount.class.getName()); | ||
| assertNotNull("No OidcAccount for token refresh", account); | ||
| RefreshableOidcSecurityContext refreshableContext = account.getOidcSecurityContext(); | ||
| assertNotNull("No RefreshableOidcSecurityContext for token refresh", account); |
| } | ||
| private InputStream getOidcRefreshConfigurationInputStream(String clientSecret, String authServerUrl) { | ||
| String oidcConfig = "{\n" + | ||
| " \"" + REALM + "\" : \"" + TEST_REALM + "\",\n" + |
There was a problem hiding this comment.
The realm isn't needed here (since the provider-url is being specified and that contains the realm)
|
Thanks @rsearls! This is looking good. You can go ahead and squash the commits. Thanks. |
8890357 to
681cfcc
Compare
| public static final String CLIENT_SECRET = "longerclientsecretthatisstleast256bitslong"; | ||
| public static KeycloakContainer KEYCLOAK_CONTAINER; | ||
| public static final String TEST_REALM = "WildFly"; | ||
| public static final String TEST_REFRESH_REALM = "WildFlyRefresh"; |
There was a problem hiding this comment.
Just one last small comment - if this is unused, it can be removed.
…dc request authentication
681cfcc to
dab06c1
Compare
|
branch 2.2.x pr #2282 |
|
Hi @rsearls , just checking if this PR can be closed? Since it is resolved in 2.6.4.Final |
|
closing as this was resolved in 2.6.4.Final |
|
Yes. I closed it. Thanks.
…On Tue, Jul 8, 2025 at 4:52 AM Diana Křepinská ***@***.***> wrote:
*Skyllarr* left a comment (wildfly-security/wildfly-elytron#2277)
<#2277 (comment)>
Hi @rsearls <https://github.com/rsearls> , just checking if this PR can
be closed? Since it is resolved in 2.6.4.Final
—
Reply to this email directly, view it on GitHub
<#2277 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD3X45EFK4WQPQVEOSVBQL3HOBFRAVCNFSM6AAAAAB3URPSVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANBXHE3DKMBQGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
…dc request authentication
https://issues.redhat.com/browse/ELY-2903