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 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.

Hello,

I am currently trying to modify the "Authorized Redirect Urls" of the FusionAuth application so that another application's post_logout_redirect_uri works as intended. Modifying the default FusionAuth application does not seem possible from the UI but it does seem possible by using the API and a PATCH command, according to documentation and this github issue: https://github.com/FusionAuth/fusionauth-issues/issues/1110.

I tried using the api call documented here: https://fusionauth.io/docs/v1/tech/apis/applications/#update-an-application, and while the response returned a 200 OK, the FusionAuth application wasn't actually updated. I then tried using the same endpoint but specified a different application, and that was updated correctly.

Does anyone know if there's any special variable I have to set inorder to enable modifications of the default FusionAuth application? I believe I am using the API correctly, since I am able to update my other Oauth 2.0 applications using PATCH, just not FusionAuth. I am also on version 1.28.1 right now. Thanks!

@pleymor yeah, it is slightly tricky, you can try decoding it here: https://www.base64decode.org/, you will get some gibberish, but the refresh token will be a substring of the decoded token. The length of the decoded token may also vary depending on your browser.

@yb98 I just figured this out, the cookie value is encoded in base 64, you can simply decode it to retrieve the actual token id.

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!