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?

@theogravity-sb Hmmm. So the issue is that someone is registering with a gmail account they control but it looks like this:

foo@gmail.com with a name of <Dan https://evil.com> which is being turned into a link?

Or am I misunderstanding your question?

You have a variety of ways to approach this, with different tradeoffs around functionality, effort and cost. It also matters if the spam accounts are being signed up for by humans or bots.

• use a webhook to prohibit bogus users from being created by setting the user.create webhook to be transactional. You'd then write a service that could examine the user object, including email address or other attributes, and return a non-200 value to fail their creation. Details on webhooks. This is available on the community plan.

• use email verification to prevent spam users without an email inbox from using your application. Details on configuring this functionality. This is available on any paid plan.

• use a self-service registration lambda, and examine the email address and other information for a user. If a user is obviously bogus or matches a pattern, you could return a message stating they can't register, or to call you for assistance. Details on using this lambda. This is available on any paid plan.

• turn on CAPTCHA which will make it harder for bots to sign up. This requires an enterprise plan.

I have self-service registration turned on. I am getting some valid users, but a bunch of spam accounts.

What is the best way to deal with this?

Thanks!

@kasir-barati Hiya, welcome to FusionAuth. Sorry, just ran across your forum post today.

There is no way to assign constraints to user.data fields within FusionAuth, but there is an open issue that I encourage you to upvote.

You can require usernames to be unique in a tenant, using the Unique usernames setting. It is, however a feature which requires a paid plan.

Another alternative, rather than

fetching all users and then looping over users
would be to search for the username before creating the user. Using the search functionality that wouldn't require scanning all the users. You can use a transactional webhook to fail user creation if your uniqueness rules are not met.

This is due to a bug in the openjdk java library that the docker image uses. You can learn more about the bug here and track our fix (which looks like upgrading the java image our docker file users) by following this bug.

Until then, the workaround is to pass this java argument at start time:

-XX:UseSVE=0

This argument disables the use of the SVE extension, which is provides "better data parallelism for HPC and ML".

You can do that with the FUSIONAUTH_APP_ADDITIONAL_JAVA_ARGS environment variable in your Dockerfile. Here's an example:

  fusionauth:
    # ...
    environment:
      # ...
      FUSIONAUTH_APP_ADDITIONAL_JAVA_ARGS: -XX:UseSVE=0

When running FusionAuth in Docker on an m4 mac, I see this error:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x0000ffff8d33fc5c, pid=1, tid=21
#
# JRE version:  (21.0.4+7) (build )
# Java VM: OpenJDK 64-Bit Server VM (21.0.4+7-LTS, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# j  java.lang.System.registerNatives()V+0 java.base
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  S U M M A R Y ------------

Command Line: -Dfusionauth.home.directory=/usr/local/fusionauth/fusionauth-app -Dfusionauth.config.directory=/usr/local/fusionauth/config -Dfusionauth.data.directory=/usr/local/fusionauth/data -Dfusionauth.log.directory=/usr/local/fusionauth/logs -Dfusionauth.plugin.directory=/usr/local/fusionauth/plugins -Djava.awt.headless=true -Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true --add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.util=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED -DfusionAuthApp87AFBG16 -Xmx512M -Xms512M io.fusionauth.app.FusionAuthMain

Host: AArch64, 14 cores, 7G, Ubuntu 24.04.1 LTS
Time: Wed Jan 22 12:35:29 2025 UTC elapsed time: 0.025614 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x0000ffff9802c010):  JavaThread "Unknown thread" [_thread_in_native, id=21, stack(0x0000ffff9e152000,0x0000ffff9e350000) (2040K)]

Stack: [0x0000ffff9e152000,0x0000ffff9e350000],  sp=0x0000ffff9e34e000,  free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
j  java.lang.System.registerNatives()V+0 java.base
j  java.lang.System.<clinit>()V+0 java.base
v  ~StubRoutines::call_stub 0x0000ffff8d337144
V  [libjvm.so+0x8338d8]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x218
V  [libjvm.so+0x80f488]  InstanceKlass::call_class_initializer(JavaThread*)+0x284
V  [libjvm.so+0x8101a8]  InstanceKlass::initialize_impl(JavaThread*)+0x528
V  [libjvm.so+0xdc7138]  Threads::initialize_java_lang_classes(JavaThread*, JavaThread*)+0xe8
V  [libjvm.so+0xdc9104]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x3f4
V  [libjvm.so+0x8c68d4]  JNI_CreateJavaVM+0x80
C  [libjli.so+0x8bac]  JavaMain+0x7c
C  [libjli.so+0xc20c]  ThreadJavaMain+0xc
C  [libc.so.6+0x8597c]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  java.lang.System.registerNatives()V+0 java.base
j  java.lang.System.<clinit>()V+0 java.base
v  ~StubRoutines::call_stub 0x0000ffff8d337144

siginfo: si_signo: 4 (SIGILL), si_code: 1 (ILL_ILLOPC), si_addr: 0x0000ffff8d33fc5c

Registers:
R0=0x0000000000000000
R1=0x0000000000000000
R2=0x0000000000000000
...

What can I do?

As of 1.51.1, we now have a dedicated health check API endpoint:

https://fusionauth.io/docs/apis/system#retrieve-system-health has more details

Hiya @maciej-wisniowski !

We do not use Apache Struts in FusionAuth.

Hope that helps.

No perfect options, but a few workarounds possible

• a connector-like proxy which would intercept Client Credentials requests from their customers and use business logic to validate the client secret against the stored Duende hash.
• stand up a simple proxy in front of the Duende that logs the plaintext client secrets for a period of time before migration (protect these logs of course)
• go to each client and ask them to use a new FusionAuth specific client secret (analogous to resetting user passwords)

More details on the first option. It requires these steps/prereqs:

FusionAuth Entities Setup

• The customer should create new FusionAuth Entities that correlate to the Client ID of all APIs and services currently associated with Duende. For now, let FusionAuth generate a random Client Secret.
• Custom Attribute for Migration: Store a custom attribute such as migration: false on entity.data for all newly created Entities.

Migration Steps

• API/Service Requests Token: The API or service calls Duende's token endpoint.
• Proxy Interception: The customer's proxy intercepts the client credentials request and searches FusionAuth Entities to find the matching Entity by Client ID.
• Migration Check: Use an if/else logic to check if migration: false exists for this client ID. If so, the proxy service proceeds with the client credentials request to Duende using the Client ID and Secret (in plain text).
• JWT Validation: If Duende responds with a JWT, this confirms the Client Secret is correct. The proxy service discards Duende's JWT and then calls the Entity API to update the correct Client Secret and set migration: true on the entity.data object.
• Complete Migration: The proxy service calls FusionAuth's token endpoint to complete the Client Credentials grant. The proxy service then returns a JWT to the end customer’s API/service, migration is complete.

Which of these make sense depend on how many clients you have, your dev teams bandwidth, and your security posture.

We're migrating from an identity provider (Duende) that hashes the client secret when the client credentials grant is used.

How can we migrate these secrets to FusionAuth entities?