-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
[fixes #4481] - RP-Initiated Logout and session verification #8512
Conversation
I'll spend a bit more time trying to figure out a way to prevent the logout endpoint from CSRF attacks. As we discussed, it seems there is no way to prevent CSRF without impacting UX. At the same time, the logout is not so risky and OPs can prevent that by asking the user if they want to log out as mentioned in the specs. So ... The way it is, it is quite simple. I'm probably going to implement logging too. |
@sberyozkin Btw, another thing we can do is to silently refresh tokens regardless of failures due to token expiration. That could allow users to have their tokens updated with whatever access information that is updated at the OP. The way it works right now is to refresh tokens only in case the token expires. |
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Show resolved
Hide resolved
@sberyozkin I'm going to work on the suggestions. I also forgot to add a concurrency check when refreshing tokens .... |
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcRecorder.java
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcRecorder.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcTenantConfig.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcTenantConfig.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcTenantConfig.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcTenantConfig.java
Outdated
Show resolved
Hide resolved
extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcTenantConfig.java
Outdated
Show resolved
Hide resolved
integration-tests/oidc-code-flow/src/test/java/io/quarkus/it/keycloak/CodeFlowTest.java
Outdated
Show resolved
Hide resolved
...-tests/oidc-code-flow/src/test/java/io/quarkus/it/keycloak/KeycloakRealmResourceManager.java
Outdated
Show resolved
Hide resolved
...-tests/oidc-code-flow/src/test/java/io/quarkus/it/keycloak/KeycloakRealmResourceManager.java
Show resolved
Hide resolved
integration-tests/oidc-code-flow/src/main/resources/application.properties
Show resolved
Hide resolved
integration-tests/oidc-code-flow/src/test/java/io/quarkus/it/keycloak/CodeFlowTest.java
Show resolved
Hide resolved
7750043
to
fca62d1
Compare
Where is the blocking call that is the problem? |
@pedroigor Hi Pedro, I was thinking about the IMHO we should instead have What do you think ? I can push it to your branch if you agree |
@pedroigor Hi, one more thing, while looking at the issue to do with dropping the redirect query params, I've realized that in this PR we will lose the encoded path parameters since VetxWeb apparently decodes |
@sberyozkin Didn't the The way it is, it just means that we refresh whenever x seconds have elapsed since the last time the user authenticated. It can be even before the session actually expires. |
@pedroigor Hi Pedro
That sounds good, yes. But I'm a bit confused. I don't think it can happen before the session expires though, as we initiate an optional refresh only when the id token expires ? So if we have But you are right :-), I may be very confused here :-) |
The token may be expired but you want to refresh only if the session in the server may be active. So, tracking from iat helps the application to refresh every time X second passes based on the max timeout of the session at the OP (refresh token). In addition to that, nothing stops us in the future to refresh the token regardless of token expiration after x second. Like I mentioned somewhere here, we may want to provide to applicatios a more dynamic behavior where changes at the OP (claims, roles, etc) are reflected to the application without a re-authentication. |
Hi @pedroigor OK, as I said it does make sense, and sounds good. (I was wondering, may be we should just have a
+1, this is very promising. I guess we'd have another property for it, say a listener which will listen in the backchannel for the updates from OP, this will drive the refresh independently from what we do now with the refresh when the ID token expires. So we will accommodate all the variations easily :-) Lets finalize this one and I think it will be ready to go in. Though I'm not sure about this refresh and blocking calls. Probably can be resolved as part of the other issue I opened... Thanks |
I think I see your point. A boolean would be easier and work too. From a UX perspective it is better. I think initially I was refreshing tokens regardless of expiration exception, thus the timeout. The name should probably change to
Yeah, we can easily do that now. I think that is one of the reasons for leaving the timeout in seconds. But we always get back to it.
|
@pedroigor OK, can you please respond to
? Thanks.
If the numbers work, then |
@sberyozkin It will not work consistently for all users. They can have different The point here is that we changed the code to only process refresh tokens when the token expires. So, for now, we can just have a boolean property as you suggested. The numbers work just fine but a boolean is much easier from a user perspective, as you suggested. Thus my proposal to name the property as |
@pedroigor I'm a bit lost, so do we go with |
@pedroigor Hi Pedro,
This means you agree, I'd like to read it this way :-). I can push to the branch, just confirm |
Yeah. I'm glad to get your changes. |
@pedroigor Thanks, I'll have a look. I was also thinking, as per your comments, that indeed introducing an interval may complement the refresh concept well (refresh it while it is not expired). Yeah, actually, having a boolean property as discussed above would apply to the expired tokens, and then to support your idea - we would just add a new property which would apply to any token even if they have not expired.
I'll open an issue to discuss later. Thanks |
Hey Pedro @pedroigor I've resolved the conflicts and pushed an update:
Once you approve my changes :-) (I can push some minor updates if needed) I will then approve and merge |
@sberyozkin I'm OK |
HI @pedroigor Thanks. I'l open a few more issues a bit later on to record your idea about the proactive recycling of the sessions based on the time interval, as well as the custom cookie for the landing post logout page. |
The review comments have been addressed
This looks like a brand new feature. Why does it have the |
No description provided.