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?

The cleanest way to do it is with asymmetric JWT verification plus a bounded offline grace period.** Here's the pattern.

FusionAuth signs JWTs with a private key it holds. The matching public key is published at the JWKS endpoint (/.well-known/jwks.json). Your mobile app — or any resource server — can verify a token's signature locally, with zero network calls, as long as it has that public key. You can even bundle the public key with the application and avoid the retrieving it.

That's the property that makes offline auth possible. You're not asking "is this token still good?" over the wire; you're asking "did FusionAuth sign this, and has it expired?" using math the device can do on its own.

See JWT signing configuration and the JWKS endpoint docs.

The Flow

1. First login (online, required). The user authenticates against FusionAuth via OAuth with the offline_access scope, or via the Login API with loginId + password + applicationId. You get back two things:

• A short-lived access token (signed JWT, RS256, EdDSA, or ES256)
• A long-lived refresh token (opaque, default 30 days, configurable per tenant or application)

Refresh token details are in the refresh token settings docs.

2. Cache the JWKS on the device. Fetch /.well-known/jwks.json once and store it. You'll match incoming tokens to the right key using the kid in the JWT header. For fully air-gapped scenarios, you can bundle the JWKS into the app at build time — see the air-gapping article.

3. Online operation. The app uses the access token for API calls. When it expires, the app calls the Refresh a JWT API with the refresh token to mint a new access token.

4. Offline operation. The app validates the cached access token locally:

• Find the key in the JWKS where kid matches the JWT header
• Verify the signature with that public key
• Check exp, iss, aud, and any custom claims you care about

If the token is past exp but the device is offline, allow a bounded grace period (e.g., 24 hours past expiration). After that, degrade functionality until the device reconnects and refreshes. For instance, you could allow read operations but nothing that changes data.

5. On reconnect. Refresh immediately. If the refresh token has been revoked server-side, the call will fail and the user must re-authenticate.

Token lifetime tuning

This is where you make your security/availability tradeoff explicit. FusionAuth lets you tune both lifetimes per tenant or per application:

• Access token TTL (ttl_seconds set this short for online use (5–15 minutes is typical), but if you want longer offline windows without the grace-period workaround, you can extend it. Whatever you pick is the maximum revocation lag for compromised tokens.
• Refresh token duration: default is ~30 days. Use a Sliding Window with Maximum Lifetime policy if you want active devices to keep working but inactive ones to expire automatically.
• One-Time Use refresh tokens: rotates the token value on every refresh. Strongly recommended — if a refresh token is stolen and used, the legitimate device's next refresh will fail and the theft is detected.

What FusionAuth gives you for revocation

Refresh tokens can be revoked automatically on password change, MFA enrollment, or any action that prevents login. You can also call the Revoke Refresh Tokens API directly. The catch: revocation only takes effect the next time the device tries to refresh. Already-issued access tokens remain valid until their exp.

Tradeoffs you're signing up for

Be honest with yourself about this approach. These aren't FusionAuth limitations, they're inherent to offline auth:

• Delayed revocation. A stolen device retains access until the access token expires and the offline grace period elapses. Shorter access token TTLs mean faster revocation but more refresh traffic and shorter offline windows. Pick where on that curve you want to sit.
• Clock trust. Offline exp checks rely on the device clock, which the user controls. If that matters for your threat model, store a "last known server time" on each refresh and refuse to validate tokens if the clock has moved backward.
• Stale claims. If a user's roles or permissions change, the old claims persist in the cached token until the next refresh. Acceptable for most apps, not for high-stakes authorization.
• Local credential storage. If you want users to "log in" while offline (PIN/biometric to unlock the cached session), you're storing something derivable from their credential on the device. Use the platform secure storage (iOS Keychain, Android Keystore) and a slow KDF like Argon2id for any password-derived material.
• Key rotation. If you bundle JWKS into the app, you have to ship app updates ahead of key rotations (or plan to create a bunch of keys ahead of time). If you fetch JWKS dynamically, you need a cache strategy and a fallback when the cache is stale and the network is down.
• MFA degrades offline. Push and SMS-based factors require connectivity. Offline auth typically falls back to device-bound factors (the refresh token + a local PIN/biometric), which is different than your online MFA flow. Decide whether that's acceptable.

Practical starting point

Here's an example of the configuration:

• Access token TTL: 15 minutes
• Refresh token: 30 days, sliding window, one-time use
• Offline grace period (app-enforced): 24 hours past exp
• JWKS: fetched on first launch, refreshed weekly when online, with a bundled fallback
• Mandatory online check-in: every 7 days (refuse to operate offline beyond this)

Tighten the numbers for higher-sensitivity apps, loosen them for field-work apps where availability matters more than instant revocation.

Some further reading for you:

• Building a Secure JWT
• Revoking JWTs
• Token storage best practices
• Air-gapping FusionAuth

The short version: FusionAuth gives you all the primitives:

• asymmetric signing
• JWKS
• configurable lifetimes
• refresh token revocation

The offline policy is yours to design, and the design is mostly about choosing how much revocation lag you can tolerate in exchange for how much offline runway your users need.

I'm building a mobile app that needs to work in places with spotty or no connectivity (think field workers, transit, rural areas).

Can I use FusionAuth as my central identity provider while still letting users authenticate when the device is offline?

@tschlegel

Yes, there's currently no support for using a certificate.

Here's an open tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/3083

Please comment and/or upvote this with any other details that would help the product team prioritize this.

Thanks for taking the time to chat with me.

I'm sharing the feedback internally, but for future folks there were multiple issues.

• The theme was built on tweaks to the standard UI, and was moving from pre 1.62 to post 1.62. Due to the massive changes in the default theme, this was problematic.
• The way the tailwind CSS is set up and built, it's more difficult to override the default styles wholesale now.
• Additionally, it is hard to create CSS selectors to target just certain elements.

@elliotdickison please keep me honest and let me know if I missed something.

@elliotdickison I'd probably try with two Identity Providers configurations in FusionAuth both pointing to the same remote IDP.

One can have screen_hint=abc on the authorization URL and the other can have screen_hint=def, but both will have all the other parameters the same.

Then you can use an idp_hint on your create or login buttons.

I think that will work, but please let us know.

@elliotdickison Thanks for the feedback.

I'd love to chat a bit more to understand the problem.

Will send you an email.

Because advanced themes are so customizable, they can be hard to upgrade. Here's some ways to make it easier.

• When you create a new theme, start from the default version. Commit it to git before you change anything.
• Use the FusionAuth CLI to download/upload your theme during development and CI/CD.
• When a new theme comes out, clone or pull the latest from the theme history repo.
• Run this command to see what has changed: git format-patch 1.61.0..1.64.1 --stdout > update-themes.patch (this shows the changes between 1.61.0 and 1.64.1; adjust as needed for your installed version and the target version).
• Go to your theme git repo and apply the changes: git am --3way update-themes.patch which will attempt to automatically merge the changes. If there are conflicts, you can resolve them manually and then run git am --continue.

You can also use a 3 way diffing tool like diff3 or kdiff3 to visualize the changes.

These upgrade notes also provide detailed human friendly instructions on the changes.

I am using advanced themes and wanted to know how to find out what had changed in the themed pages when a new release happens.

I've read the instructions here.

There are a couple different scenarios where a login record could have a blank application Id. Usually it is #1 or #2. It occurs in scenarios where the user can have a JWT/access token that does not have the application Id in it.

1. If a user is not registered for the Application they are logging into
2. FusionAuth makes a login record when a user is created since FA makes a JWT upon user creation
3. If you use the Login API, you can log in without an App ID because you don't have to provide an application on the API call.

We have a user who has logged in repeatedly, but the application is blank.

https://fusionauth.io/docs/apis/login#search-login-records doesn't mention anything about this.

What gives?