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?

This is due to non-ASCII characters in headers causing an issue in the FusionAuth parsing code. Cloudflare sends headers with non-ASCII characters (such as cf-region: São Paulo) which triggers this issue.

This is a java-http bug that was fixed in 2024, and released in FusionAuth version 1.51.2.

So, two options:

• upgrade to a version of FusionAuth 1.51.2 or newer. This is the recommended approach, but may require some work.
• as an interim workaround, you can disable the "Add visitor location headers" option from your CloudFlare console. This should not have any negative impact, since we do not inspect those headers.

We were using a FusionAuth cloud deployment directly but now want to use Cloudflare in front of it.

We are now seeing intermittent, infrequent 502 errors.

We see errors like this in the logs

2025-06-24 14:05:09.345 PM ERROR io.fusionauth.http.server.HTTPServerThread - An exception was thrown during processing
java.lang.IllegalArgumentException: Not a valid Unicode code point: 0xFFFFFFC3 

How can we resolve this?

This is not available today without some glue code.

Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into event.info.deviceDescription .

Then you create user.login.success webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off the event.info.deviceDescription field and make a PATCH call to FusionAuth. In that PATCH call, you add this to a field on user.data.x.

Then once that PATCH is successful, the 200 response back to the user.login.success event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off the user.data.x field and puts it into the JWT.

It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)

Relevant docs:

• https://fusionauth.io/docs/extend/code/lambdas/jwt-populate
• https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success
• https://fusionauth.io/docs/apis/users#update-a-user

How can I add in custom claims in to the JWT based on a custom login field or other parameters on the login form?

I have a parameter/variable that can change between each login (like a device id) and want it to be in the access token.

This is possible in a couple of ways.

First, to allow users to register for an application on login, you need to turn on self-service registration. From the docs:

When you enable self-service registration for an application and a user who does not have a registration for that application successfully logs in to that application, the user will automatically be registered for that application, and have a registration added.

Then the question becomes, how can you disable the hosted login pages self-service registration form?

To do so, take the following steps:

• update your theme to remove the link to the "Don't have an account? Create one" link from any pages, including the login page. You can also remove all the content from the registration themed page and replace it with not implemented or similar. However, a sinister user may still be able to post to the register endpoint and create a user
• if you are self-hosting, block access to the /register endpoint using a proxy
• if you are not self-hosting, prevent self-service registration by adding an encrypted secret value to all user accounts you create via the API. Then, create self-service registration validation lambda which will examine the user object. If the user object comes through without the secret value, fail the registration. Otherwise allow it through because it is a user who has logged in.

The self-service lambda may not fire unless there are required fields on the registration form, but that behavior is undocumented and may change.

I want to allow users to freely be registered to any number of applications simply by logging in, but not be able to use the self-service registration form to create user accounts (so I don't want them to be able to use the self-service registration form provided by the hosted login pages).

I'll create all user accounts using the User API.

Is there any way to do this?

inspired by this github issue

If you go look at https://fusionauth.io/docs/ and scroll to the bottom, you'll see a new section called 'Download docs'.

This takes you to fusionauth.io/docs/llms-full.txt which is all of our documentation (5MB!) in one file so you can upload it to your favorite LLM and query it.

Hope you all find it useful.

By using a proxy or gateway that supports mutual TLS, you can use it with FusionAuth.

For example, AWS ALB supports Mutual TLS verify where the ALB does client certificate verification. Nginx has similar functionality.

If you are running FusionAuth 'bare' and terminating TLS directly at the FusionAuth server, mutual TLS is not supported.

Hiya,

Does FusionAuth support mutual TLS where the client and server both have certificates?

(I'm not talking about mTLS token binding; I understand that is not implemented per https://github.com/FusionAuth/fusionauth-issues/issues/1025 .)

Hiya,

There are currently no plans to support the full mTLS spec. We are discussing DPoP (tracking issue) internally.

However, depending on your needs, there may be a workaround.

Since the client credentials grant depends on Entities, you can leverage this to inject a client certificate hash into an access token obtained through the client credentials grant.

How this works at a high level:

• Client Certificate Registration
  During onboarding, your customer (e.g., a bank) registers their client certificate. A hashed value of that certificate is securely stored in FusionAuth (entity.data). The hashing process is outlined in the RFC.
• Client Credentials Request
  When the bank requests an access token using the Client Credentials grant, a FusionAuth Lambda is invoked before the JWT is signed.
• Augment Custom Claims
  The Lambda code looks up the stored certificate hash and injects it as a claim in the JWT. For maximum compatibility with RFC 8705, it is recommended to add this hash to the cnf object in the JWT, like so:

"cnf":{
  "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
}

• Accessing the Resource Server or API
  The customer presents both the access token and presents their client certificate when calling your API.
• Validation Flow
  Your API:
  • verifies the JWT signature
  • computes a hash of the presented client certificate
  • compares it to the x5t#S256 claim in the token
• Decision Logic
  If the hashes match, the request is bound to the correct client and access is granted to the protected resource.