Hello,

I was looking at the fusionauth.sso cookie and its value seems to be encoded, as I used the "jwt/refresh?userId" API endpoint to retrieve all currently active refresh tokens, and none of the tokens' ids matched with the value of the fusionauth.sso cookie. However, when I look at the value of the fusionauth.session cookie, it corresponds perfectly with the id of the refresh token for the FusionAuth session.

I am wondering why one of the session cookies corresponds to the id of a refresh token (fusionauth.session), whereas the other (fusionauth.sso) does not, perhaps one is encoded and the other is not? Thanks!

@dan Thanks for the reply Dan, I'll go ahead and discuss this with my team before we go any further.

Just to double check, could the FusionAuth team revise this document's flow chart of the logout request if it's no longer correct? https://fusionauth.io/docs/v1/tech/guides/single-sign-on, or perhaps specify that the Logout request is specific to the FusionAuth app, not Pied Piper? Thanks.

@dan

Thanks!
I made the new issue https://github.com/FusionAuth/fusionauth-issues/issues/1907

@dan

Thanks for the reply.
No, this is only occurring for LDAP users. The issue is with the first browser, if I attempt to access a new OAuth linked application, because the refresh token is not valid anymore and accessing this new endpoint will cause authentication with the existing token, I will be incorrectly prompted to log in. If I am just switching between tabs, then there is no weird behaviour as it does not attempt to authenticate me.

So because I have made a new SSO session in the second browser, the existing SSO session in the first browser is no longer valid.

It seems like the fusionauth.sso cookie can no longer be base64 decoded after upgrading to a new version (it was previously decoded with base64 on version 1.28: https://fusionauth.io/community/forum/topic/1103/fusionauth-sso-cookie-s-value-is-encoded).

Is there a specific algorithm used to encrypt/encode the refresh token into a fusionauth.sso cookie? By refresh token I mean the refreshToken.token parameter returned by this api call https://fusionauth.io/docs/v1/tech/apis/jwt#retrieve-refresh-tokens. We were previously using base64 decryption to match the fusionauth.sso cookie in the browser with a specific refresh token to monitor and modify user activity.

Thanks!

Hi,

I came up with a quick test where I logged in as the same LDAP user into two different browser sessions. The first login into browser "A", produced a refresh token "A" for the user, and I was able to confirm that there now existed a session for the user when examining their sessions through the FusionAuth UI. When calling the API, I also confirmed that one refresh token was present.

However, when I logged into a second browser "B" with the same LDAP user, the refresh token "A" was replaced with refresh token "B", which corresponds to the new SSO session. This made it so that the SSO session in browser "A" was no longer tracked by FusionAuth, calling the API revealed only refresh token "B" was present. When examining the list of user sessions in the UI, only the second session was present.

Is this intentional? This would mean that only the most recent sessions for LDAP users are available inside of FusionAuth for modification or deletion. The LDAP reconcile I am using is also not setting any values related to the refresh token. Thanks!

@dan Thanks for the reply Dan, I'll go ahead and discuss this with my team before we go any further.

Just to double check, could the FusionAuth team revise this document's flow chart of the logout request if it's no longer correct? https://fusionauth.io/docs/v1/tech/guides/single-sign-on, or perhaps specify that the Logout request is specific to the FusionAuth app, not Pied Piper? Thanks.

@dan Thanks, I just commented.

@dan Hi Dan, thanks for the reply.
To answer your questions:

1. I am using FusionAuth version 1.28.1
2. Logout Behaviour for every configured application is set to "All Applications"
3. The user who is logging out is registered to all applications, including FusionAuth.

Could this also be due to the fact that the "logout url" for FusionAuth's oauth configuration is set to "/admin" instead of "/admin/logout"?

Thanks.

I am currently trying to trigger a global logout using the /oauth2/logout endpoint.

However, it seems that when I execute the following url: https://.../oauth2/logout?client_id=27c57f2e-1b0f-4596-b742-e7e8d7d80fa3, the user's fusionauth.sso cookie is removed and they are signed out of all Oauth 2.0 applications except for Fusionauth (which I believe relies on the fusionauth.session cookie). If however, I replace the client_id with that of FusionAuth, then I do get logged out of all applications, FusionAuth included. Only problem with the second approach is that I can no longer use any post_logout_redirect_url arguments, as the FusionAuth application's list of authorized redirect urls cannot be edited. I did come up with a partial solution by configuring my network to remove the fusionauth.sesson cookie, but that just removes the session from the browser, not the session itself.

Is this behaviour intentional? Thanks!

Hi Josh,

Thanks for the reply.

Our current use case is as follows:

1. User signs into an application (Grafana) via Oauth, this application is registered within FusionAuth
2. The user then logs out of Grafana, this should terminate their SSO session and sign them out of all applications, but it doesn't somehow. I have tried setting the logout behaviour to "All applications" but this doesn't make a difference.

To address that second point, I modified Grafana to redirect to FusionAuth's logout url (/admin/logout) which results in a global logout. This is how a global logout is achieved in Grafana it seems (https://github.com/grafana/grafana/pull/12077).

However, when the user does logout of Grafana, because they are redirected to Fusionauth's logout endpoint, if they attempt to login again (without changing tabs), they will be signed into FusionAuth. Therefore, I was thinking the post_logout_redirect_uri could be used, while it does attempt to redirect the user back to Grafana after logging out from FusionAuth, it ultimately fails as the origin of the request is not listed as one of the "Authorized redirect urls" inside of the FusionAuth application, this is why I was hoping we could modify the "Authorized redirect urls" using the API.

Hello, I was wondering if it would be possible for FusionAuth to save a user's registration information after they have logged in via LDAP?

The issue we are currently facing is that our customer's LDAP does not contain any information pertinent to a user's registration, rather, LDAP is used in this scenario for authentication only. As such, the reconcile lambda code does not modify the "registrations" attribute of the user, this field is left blank each time the user logs in via LDAP and the resulting user is created inside of FusionAuth without any registrations.

After the user account has been created inside of FusionAuth, they can be assigned roles using the UI. While these roles are saved inside of FusionAuth, it seems that the next time the user attempts to log in via LDAP, their account inside of FusionAuth gets recreated according to the reconcile lambda, as such, they have no registrations again.

Is it possible to designate the LDAP connector to perform authentication only? Or to mark a user account to not get recreated each time it uses LDAP to sign in?

I do know we can migrate the user to FusionAuth, but this will not address issues if the user's account changes within LDAP. I am also aware that there is currently an open issue to allow for the reconcile lambda to communicate with the API (https://github.com/FusionAuth/fusionauth-issues/issues/267), which would solve this issue entirely. Furthermore, it may be possible to implement our own authentication API using the generic connector, although this approach will take longer to implement.