@dan I've raised a new feature request to add this functionality to Fusion Auth. The webhook idea was interesting, but there is no call when the one-time JWT refresh token is "re-used". Therefore, I can't detect the scenario and revoke the chain. The alternative is to open the JWT refresh token to be re-usable. That's another set of security issues that I don't want to have in the system.

I've raised the issue here: Issue #1619

We are trying to utilize refresh tokens in a SPA web site. To do so we had to reduce our security settings by not requiring client authentication so that it was able to exchange the refresh token for an access token.

We are okay with this since we also have "require PKCE" if no client secret is passed in, but wanted to verify that the refresh token itself was not a source of risk.

I can't prove that the refresh token (essentially a bearer token now) is either:

1. Sender Constrained
2. Refresh Token Rotation Implemented

We did a test for #2 with "one time use" on, expecting the refresh chain to be rejected in the detection of an "attack".

Issue a /authorize and get a code
Exchange code for tokens (includes refresh token)
Use refresh token to get a new (access token, refresh token) pair
Use OLD refresh token again to attempt to get a new pair, this fails [so far so good]
Use NEW refresh token from step above to get a pair

The expectation is that the NEW refresh token is revoked due to the "attack" detected with the use of the OLD refresh token. Essentially we should assume that the credentials were stolen and used maliciously.

However, that doesn't happen with FA. Instead, the refresh token is allowed to get a new access token.

This allows the following attack:

1. Attacker/Malicious code gains access to refresh token
2. Attacker immediately uses refresh token to gain new access token
3. Real code attempts to get a new access token and is refused due to one-time
4. Attacker continues to use refresh chain to access application

I'm trying to prove that refresh tokens are "safe" to use in a public client and would like some guidance since I can't find any information about how the above attack is mitigated in Fusion Auth. Does anything else mitigate this attack?

Thanks!

PingIdentity Blog Post on Refresh Token Rotation

Auth0 Blog Post on Refresh Token Rotation

Interestingly, we are also looking at using this self service module as an "embedded" page in our application. If the user doesn't select "remember me", how would one pass the authentication information from the logged in application to this module?

Is embedding / using this page inside another page (without requiring a second login) a use case for it?

This is a carryover from this issue: https://github.com/FusionAuth/fusionauth-issues/issues/484

The end use case I'd want is:

Add a user to the tenant with an email or username (depending on linking strategy)
Add user to a group
Add registration for user to the various applications (is there a way to do this via the Group > mechanism above?)

This way when the user first logs in, they have access to the systems they need.
We do not want self registration, and self registration requires them adding a password which we do not want (no way to create a form without a password that I've seen so far).

Thanks for clarifying your end use case.
You should be able to do this via a provisioning script:
add a user to a tenant with an email or username (depending on linking strategy) with a random password that they never need to know
add the user to a group
add a registration to the user for particular applications
When you present the login form link to the user, specify an idp_hint so they are never shown the password field. In fact, you could edit the theme to remove the login id and password fields as well.
You can not specify a registration via a group, only a role to be assigned after registration.

Hope that helps. This has moved away from the issue and is probably more of a forum topic at this point. If you have additional feedback, let's discuss on the forum (feel free to paste a topic link here).

So this kind of works. But starts to be less than ideal as we make the use case extend to the full one:

The tenant is a mix of IdP and UN/PW users. Therefore, removing the prompt for all users won't work, but if we had a 100% IdP tenant, I can see the benefit of that and idp_hint.

When a user uses the self edit page from Fusion Auth they would be able to "change" this password, but since they don't know the original it would just be broken functionality. Is there a way to suppress this on the self editor page and/or detect that the user was an IdP managed user? We want to use that to allow them to enable MFA and (for users with passwords) change their password.

This is less of a concern with our internal employees (we can train them to avoid this part of the profile editor). But if we start to link 3rd party IdP to the system for our customers it may become a source of support issues ("why can't I change my password here?").

I've read the various documents and have a few questions about how to deal with more advanced scenarios.

I have a set of organizations that have multiple "products". I also have a set of micro-services that coordinate together to produce those "products". Within that product, some of the micro-services are likely coordinating to produce "tools". That results in the following hierarchy:

• Organization
  • Product Suite
    • UX Tool / API
      • Microservice

My goal would be to have a single sign on for the entire organization, so that all products are signed into. Users have different roles for all the various tools, and those are what the users would primarily be logging into.

Therefore, I've mapped:

Hierarchy	Fusion Auth
Organization	Tenant
Product	no mapping
Tool/API	Application
Micro-Service	no-mapping

For "general" roles (admin, user, etc.) and allowing a user to use a tool/api the user would have a registration record for the particular tool/api and a set of roles assigned to them.

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 also have a new requirement and I'm not sure how to map that in fusion auth. I've looked into Entities - but am very confused by them and not sure if they are meant for this use case or not. That requirement is that a particular user may have different roles in the same tool/api based on the "context" they are trying to work with.

For instance, we could have multiple "customers" in the tool and some users would have different permissions sets based on which customer they are looking at. (For instance, a user would have no access to some customers, management roles/capabilities of a subset of the customers and read only visibility on others).

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

Thanks!

@alan-wood said in Federated Authentication Scenario Possible?:

After verifying the user is legit, require them to consent to one or more consents in the system, also possibly asking them for additional information before letting them in.

For the advanced registration piece, it would make more sense to me if that wasn't tied to a username/password at all. If we already have the un/pw in a federation situation, then forcing us to ask for it again to fill out the registration record seems incorrect.

I understand that for a B2C where someone is creating a un/pw on the site it makes sense. However, there are many instances where we don't want to have a user able to login via any means other than federation (AD login, social media login, etc). And even where it "may" make sense (multiple social media logins linked to the same record) - there might be a "username" but certainly no password would be required in those cases.

The custom claims makes sense, and I'm happy to do something like that.

If I wanted to inject my own screens into the middle of your hosted UX flow, how would we do that? [Basically add my own "advanced registration" flow into your UX flow]?

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

We have a need to handle multiple regions for our application since we are a world wide organization.

Part of that is handling PII in a safe manner (which user names and emails are a part of).

This may require us to isolate some users to certain authentication regions due to local regulations. In addition, we may want multiple authentication regions for latency reduction (no reason for a slow link to cause users to get frustrated).

A few questions:

1. Is there a way to synchronize users across multiple FusionAuth cloud installs so that we can serve the user an API from a close region instead of a high latency link?

2. If we isolate a region from another (meaning we don't use #1 above) is it feasible to share the keys using KeyMaster between the regions so that a JWT token generated by region 1 can be used to access region 2?

3. Can we scrub the JWT token of any PII before sending it to the front end so that if we send the JWT cross region we are not sending PII inadvertently?

Thanks!

I'm reviewing FusionAuth (paid edition) and the scenario I want to be able to accomplish is the following:

1. Login using an Identity Provider (Federated Login) - using idp_hint works great to force this.
2. After login reject some users from the provider if they aren't in certain groups (this works by using a lambda function and throwing an exception during it)
3. After verifying the user is legit, require them to consent to one or more consents in the system, also possibly asking them for additional information before letting them in.
4. After login, verify that the user has MFA setup in FusionAuth, if not force them to do this

So, the MFA piece appears to not be available yet without custom UI work - waiting on issue #960 to hopefully allow this to happen.

The consent piece, I thought I could use the advanced registration forms, but those require a (un/email, password) field set to be present. In the case of federated logins, I don't want that to happen since I don't want to own the user's password at all.

Is there a way to gather "additional data" for the user profile without requiring them to have a un/pw in the system like this with the hosted UI?

If not, is that something on the roadmap?