Topics created by yb98

This is something that is a potential issue for us as well.

The other big implication of the user being recreated/fully resynchronized is that not only are the registrations removed, but so is any multi-factor authentication that was set up on the user.

@yb98

I think what you are looking for is OAuth's back-channel logout. This is under consideration under ticket 465.

https://github.com/FusionAuth/fusionauth-issues/issues/465

As a workaround, you would have to use a backend (or another environment that can appropriately hide credentials) and make a call to revoke the refresh token on a user.

I may be misunderstanding your workflow, but I believe the above should point at a possible solution.

Thanks,
Josh

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

You should be able to use the LDAP connector but when configuring at the tenant, set Migrate User to false.

That will ensure that the user data doesn't migrate to FusionAuth. I realize this doesn't address your desire to not grant FusionAuth read credentials. Feel free to file a feature request for that specific feature: https://github.com/fusionauth/fusionauth-issues/issues

Ideally, a user would attempt to log in with their LDAP credentials into FusionAuth, and then FusionAuth would forward these credentials to LDAP for authentication.

If this is a requirement, you could do this using a lightweight JSON API you write which talks to LDAP and a generic API connector: https://fusionauth.io/docs/v1/tech/connectors/generic-connector/

Your application needs to kill/destroy its session in the Logout URL route.

For example, see the "Logout page route" here: https://fusionauth.io/docs/v1/tech/guides/single-sign-on/

Do your applications do that?

@yb98 thanks for explaining. I don't see an easy way to do what you want with kickstart alone, since you can't set the age of the password programmatically. The same issue would occur if you did this all via an API. The only thing I can think of is to apply the password complexity rules 1 day after system startup. A pain, I know, but that's the only path I see that would work.

Hi @yb98 -

I don't believe that this is currently possible within the Admin UI (but I will update this post if I discover otherwise). You could submit a feature request outlining your use case.

It may be possible to hook something up via the API and lots of custom code (but even then, I am not sure how this would work). You may find some insight here.

Please note, you can set these duration settings on both the tenant and the application level (example below).

Thanks,
Josh