Topics created by alan.wood

@alan-wood Hmmm.

First, thanks for filing the issue. I appreciate it.

but there is no call when the one-time JWT refresh token is "re-used".

Second, I'm pretty sure the webhook idea will work. Here's my thoughts:

User 123 logs in, gets refresh token A Use refresh token to get a new (access token, refresh token) pair System catches jwt refresh event and records token A for this user (so the userId 123, token A pair). It generates token B. Use refresh token A again to attempt to get a new pair, this fails [so far so good] The webhook should fire again and records that token A was used again (by looking up the refresh token value in the pair). Uh-oh! Fire off an event to revoke all refresh tokens for the user 123: https://fusionauth.io/docs/v1/tech/apis/jwt#revoke-refresh-tokens Using refresh token B will fail, because all refresh tokens are revoked.

Have you tried this approach? What am I missing?

and/or detect that the user was an IdP managed user?

In the reconcile lambda from the IdP (here's the docs for the OIDC lambda), you can set whatever data you want on the user.data field, so you could set user.data.idpUser = true. Then you can access that value from the self edit page freemarker template and decide to show or hide the password field.

I get that this isn't as straightforward as it would be if the original feature request was implemented 🙂 . But I think there's a path forward here that doesn't wait on that.

It would appear that you are requesting functionality similar to scopes in OAuth:

https://github.com/FusionAuth/fusionauth-issues/issues/218
https://github.com/FusionAuth/fusionauth-issues/issues/275

Please upvote these issues if they apply to your use case.

I don't see a way to manage "permissions" in fusion auth (what a role would allow a user to do) - so I assume that concept would be left to the individual micro-services to handle.

I believe that you are correct. You would have to write this integration code.

Roles can be used. They are entirely free form. Meaning you can assign the role of "monster_maker_person" to a user and define what the role can and cannot do at the integration code level.

A few other customers have unique implementations regarding roles and permissions. You can read more (at a high level) about them below.
https://fusionauth.io/blog/2021/06/15/sunfinity-fusionauth-python/#undefined

First question is if my "mapping" follows the best practices for fusion auth. I want to make sure that I don't map in a way that means I'll be fighting with the solution.

The answer to this question might be in the details of the integration. From afar, it seems reasonable to me. We do offer professional services/contracts should you need additional support in your integration.

Second quesiton is, how would the community suggest that we model the new requirement in fusion auth, or is the capabilities of fusion auth not a good fit for this use case?

After browsing our open issues (https://github.com/FusionAuth), feel free to log your own use case if not covered.

I hope this helps!

Thanks,
Josh

@alan-wood,

In reviewing with the team, looks like there is another path forward regarding original bullet #3

Add an Idp (you could use google for instance) Add a consent from settings > consents Add a form field referencing this consent Make an advanced registration form Add previously created form field/consent to this form Create a new theme (or extend your existing non-default/shipped theme) Modify the theme to remove the display of the username and password in FreeMarker Navigate to customizations > themes > all affected templates (in my case, this was the OAuth register template)

Here is the simple Freemarker that I used to modify (disclaiming now that you may want to rework this code a bit -- example only)

[#-- Begin Self Service Custom Registration Form Steps --] [#if fields?has_content] <fieldset> [#list fields as field] [#if field.key == "user.username"] [#elseif field.key == "user.password"] [#else] [@helpers.customField field field.key field?is_first?then(true, false) field.key /] [#if field.confirm] [@helpers.customField field "confirm.${field.key}" false "[confirm]${field.key}" /] [/#if] [/#if] [/#list] </fieldset> <div class="form-row"> [#if step == totalSteps] [@helpers.button icon="key" text=theme.message('register')/] [#else] [@helpers.button icon="arrow-right" text="Next"/] [/#if] </div> [#-- End Custom Self Service Registration Form Steps --] Now when I see my register page, I get view like this. The Idp that you select will use the hidden username/email and password fields.

You are going to want to also customize the label for the consent. More information can be found below.
https://fusionauth.io/docs/v1/tech/guides/advanced-registration-forms/#consents

804d24ad-6884-411f-812e-85cb26406b7b-image.png
⬇ ⬇ ⬇
1b22fb15-8544-4b19-a267-54aeea3236ad-image.png

Does that require completely replacing the UX flow you have with my own hosted one?

Yes, I believe that you would have to do this to add your own pages.