I'd like to update the user data object in the UI. I know I can do it via the API: https://fusionauth.io/docs/v1/tech/apis/users

https://fusionauth.io/blog/2021/04/01/fusionauth-introduces-simplepass/

I have a quick question about FusionAuth and configuring the inactivity timeout of the session cookie it creates. Specifically... Is it possible?

There's now an open source terraform provider available: https://github.com/gpsinsight/terraform-provider-fusionauth

It's also on the registry: https://registry.terraform.io/providers/gpsinsight/fusionauth/latest

Can you run FusionAuth in Kubernetes?

Is modifying the JWT via a lambda equivalent to accessing the verified property of the user profile?

Within a lambda, you have access to the user and registration properties. So you'd pull the verified property from wherever you wanted and put it into the JWT as a custom claim. Here's a blog post about how that might work.

So yes, it is the same data. It's the tradeoff between a bigger JWT and having to make the additional call from your API.

Don't forget that the JWT will live for a while, so if this sequence happens and you use the JWT, you might have a user with a verified email prevented from using the API.

1. user registers
2. JWT issued, with verified set to false because the user isn't verified.
3. User verifies their email
4. User visits API, but is denied because the JWT has stale data.

I don't know timelines and how long your JWTs live for, but this is something to consider. Does that answer your question?

Symmetric keys are not returned on the JWKS endpoint, as they don't have a public key. Per the docs this api:

returns public keys generated by FusionAuth, used to cryptographically verify JWTs using the JSON Web Key format

If you create an RSA or EC key which is an asymmetric key pair - the public key will be returned on the JWKS endpoint. If you don’t have any key pairs configured , it will be empty. Out of the box, you’ll only have one HMAC key which we don’t publish in JWKS.

Ah, I just tested this out and if you don't need it in the JWT, you should be able to see it in the registrations object returned after login.

Here's a response I get after logging in:

{
  "token": "ey...",
  "user": {
    "active": true,
    "connectorId": "e3306678-a53a-4964-9040-1c96f36dda72",
    "email": "email@example.com",
    "id": "2df13f18-01cc-48a4-b97a-2ab04f98d006",
    "insertInstant": 1592857899119,
    "lastLoginInstant": 1596819645662,
    "lastUpdateInstant": 0,
    "passwordChangeRequired": false,
    "passwordLastUpdateInstant": 1592857899145,
    "registrations": [
      {
        "applicationId": "78bd26e9-51de-4af8-baf4-914ea5825355",
        "id": "73d2317b-d196-4315-aba2-3c205ed3ccae",
        "insertInstant": 1592857899151,
        "lastLoginInstant": 1592857899153,
        "lastUpdateInstant": 1596813810104,
        "roles": [
          "Role1"
        ],
        "usernameStatus": "ACTIVE",
        "verified": true
      }
    ],
    "tenantId": "1de156c2-2daa-a285-0c59-b52f9106d4e4",
    "twoFactorDelivery": "None",
    "twoFactorEnabled": false,
    "usernameStatus": "ACTIVE",
    "verified": true
  }
}

So user.applicationId.roles is what you want. Note that roles are applied on an application by application basis. If a user is in a group which has a role 'roleA' which is created in 'applicationA', but is not registered for 'applicationA', they won't receive that role. More on that here: https://fusionauth.io/docs/v1/tech/core-concepts/groups

OK, we just released 1.18.8 and that is the version you want to use:

In requirements.txt:

fusionauth-client==1.18.8

And then this is the call you want to make (with client_id before redirect_uri) :

 resp = client.exchange_o_auth_code_for_access_token(request.args.get("code"), client_id, "http://localhost:5000/oauth-callback", client_secret)

Hiya,

First off, we'd recommend having all the flow you outline be over TLS. That's good enough for most major ecommerce systems and so shouldn't be insecure. If you aren't serving your application over TLS, then I'd advise doing so. And note that the flow is actually:

My Frontend --> My Backend --> FusionAuth API

There's no password returned from the registration API call.

If you are concerned about a new user's password being insecurely transmitted through your application, you could use the FusionAuth hosted login pages and theme them to be like your application. (More docs.)

The other option, which takes encrypted passwords, is the Import Users API, but that's probably not a fit for one off registrations. There are no plans to accept encrypted passwords for one off user registrations. Here's a related issue you can weigh in on/vote up if you'd like. Or feel free to open a new issue if that one doesn't capture the essence of your idea.

Are there specific security concerns you have around your front end/back end systems that I might be missing?

It's a subtle difference, but one-time use refers to the value of the refresh token, which you use against the /oauth2/token endpoint to get a new access token via the refresh grant.

A sliding window refers to the refresh token itself, which has a unique id which stays the same, even as the value of the refresh token changes.

So if you had a refresh token with a lifetime of 4 hours, a sliding window and one time use configured, you might end up with something like this:

• at creation: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value RNhY5yE39t1o2FXKxgyH, lifetime 4 hours
• when the RT is presented to the /oauth2/token endpoint 3 hours after creation: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value Fh95KZLfSMjMNxpR5B4c, lifetime 4 more hours
• when the RT is presented to the /oauth2/token endpoint 3 hours later: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value baHneP4s0hBHPEk88GPC, lifetime 4 more hours

More details here: https://github.com/FusionAuth/fusionauth-issues/issues/2925

If you have one-time use refresh token, then every time it is used, you get a new refresh token.

If you have a refresh token with a sliding window, every time you use it, its lifetime is extended.

How are these settings compatible?

Here's the PR making the doc better:

https://github.com/FusionAuth/fusionauth-site/pull/3371

Also, why doesn't FusionAuth expose the default signing key, HS256, at http://localhost:9011/.well-known/jwks.json?

@fusionauth-qhj5e We don't publish the HMAC key to JWKS.json because if we did, anyone would be able to find it, and sign JWTs as your FusionAuth installation. HMAC keys should only be used when both parties can share a secret.

I'll update the docs to make that clearer. Sorry!

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints#json-web-key-set-jwks

@sspinn Hiya, I'm in the admin console pretty regularly and haven't seen this behavior.

Can you narrow down the replication steps so we can try to recreate?

Which version of FusionAuth you are running and what database you are using will also be helpful.

Another option that works as of today is to set up a tenant to tenant connector.

Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.

Change your app to send everyone to a new application in the new tenant.

When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.

This slow migration takes time, but is another option.

Hi @jamesbaxter . Sorry, just saw this now. I don't have the example app available. Sorry!

When I navigate to the Reactor page, it shows that it's licensed with a Community Edition license.

Custom form fields require a starter license, and because you modified the form field names, FusionAuth thinks you are trying to use a custom form field. (Note, I'm not suggesting you buy a license--this functionality should work in community edition--but I wanted to explain why you are getting the message.)

With the move to 1.53.2 did you upgrade or use a new instance? If the former, does the issue still appear in a new install?

FusionAuth Cloud instances may or may not have static egress IP addresses; please open a support ticket with your instance name to learn more.

VPC peering is not currently supported, though that issue is the right one to follow for future developments.

You can also use an LDAP proxy to solve this issue.

FusionAuth -> LDAP proxy -> AD

where the LDAP proxy is in the DMZ and AD is configured to only talk to internal network values or the LDAP proxy.

Here's a StackOverflow post with more details.

I want to lock down access between ActiveDirectory and FusionAuth running in the cloud. What is the best way to do that? Can I use VPC peering? It appears to not be supported: https://github.com/FusionAuth/fusionauth-issues/issues/1147