Wonderful blog post. I found it very helpful and informative. Solar

Any news?

@egg said in Maximum lifetime of refresh token not honored? (sliding window configuration):

I am configuring my Tenant with a refresh token expiration policy of "sliding window with maximum lifetime". I have configured the maximum lifetime to 240 minutes, but the refresh token is actually expiring after 30 minutes.

The "sliding window with maximum lifetime" policy should allow the refresh token to remain valid as long as it's used within the configured lifetime, which in your case is set to 240 minutes.

@tvdlooy were you able to resolve this?

@zaalbarxx sorry for the delay. I might be missing it (sorry not a PHP person) but I don't see where that confusion comes into play. I know that some of our docs had to get updated because of a change that we made during our 1.50 release that required to request further details in our scopes request.

This release makes significant changes to the default behavior of new Applications with regard to scopes in OAuth workflows. The database migration will update existing Applications to behave in a backwards compatible manner. See the OAuth Scopes documentation for more information, in particular the Relationship, Unknown scope policy, and Scope handling policy configurations.

https://fusionauth.io/docs/release-notes/#version-1-50-0

Let me know if that still isn't making sense, or if there is a spot you were hung up on and I would be happy to update our docs. Or even better feel free to add a PR.

@mark-robustelli Hi, Mark. This is a great idea I didn't even think of. Thank you very much. It is a workaround anyway, but maybe it will allow me to complete PoC and wait for the proper invite flow to be implemented in FA.

Thanks for addressing this use case. Your proposal, however, runs counter to any standardization effort: Long live OAuth! 🙂

A better approach would be to switch from a password grant to the use of authorization codes (instead of passwords) to obtain the access token. This is fully within the OAuth framework and does not introduce fusionauth-specific hacks into the solution.

We have created as simple html page that redirects to the fusionauth authorize endpoint with grant_type=authorization_code. The browser handles MFA as usual. Upon redirecting to this page, the page can harvest the authorization code for the user to copy. From there proceed with into authorization code in place of a password.

PS: Long live OAuth!

@alan-rutter When it comes to account recovery in a passwordless login system, the most recommended method is to use a self-service approach. This means allowing users to recover their accounts themselves, which not only saves administrative costs but also saves the user's time. The simplest form of account recovery, and the one most amenable to automation, is a “forgot password” flow. This should be part of any Customer Identity and Access Management (CIAM) system.

In the context of passwordless authentication, this could involve sending a one-time code or a magic link to the user's registered email or phone number. The user can then use this code or link to authenticate themselves and regain access to their account. This method is secure and user-friendly, as it does not require the user to remember any passwords.

For more information, you can refer to these articles on account recovery and passwordless authentication.

@david-gonzalez I created a new user test@test.com and added the FusionAuth Registration. I granted it the Report Viewer role and was able to log in and see recent logins on the Dashboard. (I assume that is what you are talking about.) I got curious and removed the Report Viewer role and added the Event log viewer role. That allowed the test user to see the Dashboard as well. Will one of those two roles work for you?

@prince-b What scopes are you requesting?

@zaalbarxx Currently, FusionAuth does not support the use of macros for reusing content across different email templates. There is an
open issue on GitHub discussing this feature. I suggest you up vote it.

Hmmm.

Did some research and there's no way to straight forwardly have Discord delegate user management to an IdP.

This is in contrast that with other tools like Zendesk which let you do this pretty easily.

Of course, you can go the other way (have users log in with Discord) but that's not what you are asking.

There are some workarounds, but they require custom discord development. Here are some options:

Create a discord application that adds users to a server based on the oauth2 flow with the guilds.join scope. set that application up in a way that people need to sign in with FusionAuth and link that signup to their discord account. Your discord app that handles said oauth2 flow. Then you add users through that app instead of invite links. Use a public server but lock channels behind a role which gets added upon authorizing with FusionAuth by your bot. You could also use linked roles with a general access role people can opt into, if they fulfil the requirements set by that role (which you could control via registration at FusionAuth).

There's lots of documentation on creating discord bots but I don't have a specific example of any of these solutions, sorry.

@david-4 , Is this what you are looking for? Using Replacement Variables

I've tested on 1.50.1 and I am able to see the usernameClaim in the response body.

However, that field is something that is not set by default and will only show up if that field has a value in it, otherwise it will not be in the response body.

@alan-rutter

Thank you for your answer, I will check that out, but it is really blurry in my mind as of now!

@Alex-Patterson No, I've been using 1.50.1 version of FusionAuth (read from the admin panel) all the time. The only thing that changed was provider version. Like I said I can just switch between versions and it will start/stop working immediately, so I assume that version 0.1.106 may add some implicit parameter which changes something.
I just checked it after using docker-compose down -v and docker-compose up (fresh installation) and after running the Terraform the error still persists. What's interesting is that I've checked the diff between 0.1.105 and 0.1.106 on FusionAuth Terraform repo https://github.com/FusionAuth/terraform-provider-fusionauth/compare/v0.1.105...v0.1.106 and it does not seem that anything that could be related was changed there, maybe it is related to Go client or something ?

EDIT:
Ok, I found the culprit, looks like between 0.1.105 and 0.1.106 there is some change that automatically sets this to either false (106) or true (105):

Application -> Scopes -> Provided Scopes
Here there are some default scopes, address, email, phone and profile.

The problem here is that it looks like the Terraform provider currently does not allow to set these variables in schema, so basically we are blocked between older version with unsupported configurations like theme's oauth_consent and newer version which handles these scopes inproperly (we can change it manually, but obviously each deployment will cause the values to reset back to false).

https://github.com/FusionAuth/terraform-provider-fusionauth/issues/277

I hope this will get resolved quickly since right now it is quite a blocker.