Topics created by dan

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

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.

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,

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.

@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?

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

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.

While I have not tested it, this documentation shows how to use an SMTP integration to send an email with resend.

This should work fine with FusionAuth's email settings.

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

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.

The best way to see this is to visit the theme history github repo.

It is mentioned in the theme upgrade documentation.

Currently this is not editable in the Admin UI. This value can be set by calling the Tenant API, however.

Docs here: https://fusionauth.io/docs/apis/tenants#update-a-tenant

I was able to do this by:

copying the advanced theme editing it navigating to the Helpers file inside that, going to the head freemarker macro

I removed these lines:

<link rel="stylesheet" href="/css/font-awesome-4.7.0.min.css"/> <link rel="stylesheet" href="/css/fusionauth-style.css?version=${version}"/> [#-- Theme Stylesheet, only Authorize defines this boolean. Using the ?no_esc on the stylesheet to allow selectors that contain a > symbols. Once insde of a style tag we are safe and the stylesheet is validated not to contain an end style tag --] [#if !(bypassTheme!false)] <style> ${theme.stylesheet()?no_esc} </style> [/#if]

If you want to use the CSS field in the theme to store your CSs, leave in

[#if !(bypassTheme!false)] <style> ${theme.stylesheet()?no_esc} </style> [/#if]

which pulls in the CSS associated with the theme. Doing so allows you to add all your custom CSS to the CSS field in the theme and have it automatically included. If you don't do this, make sure you add your CSS to this macro (either directly or via a link). You'll want to make sure you keep it in as you upgrade.

Removing all the CSS will result in a page that looks like the one below.

unstyled login page

There is no webhook for this. You have a couple of options.

When the login event happens, you can look up the refresh token associated with that login event. You'd match based on application and time.

Then you can look up the application or tenant level refresh token lifetime and calculate out when the refresh token will expire.

Depending on the refresh token usage settings, refresh token lifetime might extend based on usage, so you might need to recalculate the lifetime based on that.

Then you'd know expiration time and refresh token id by querying this dataset.

You can also poll FusionAuth directly, using the APIs. You'd still need to keep track of valid refresh tokens in a separate datastore, then use the APIs to pull the valid refresh tokens. You can pull refresh tokens by user, but not at a coarser level of granularity. When you do so, use startInstant combined with the application or tenant level refresh token configuration.

The easiest thing to do is to store the value on the user.data object in the reconcile lambda, and then pull it off in the JWT populate lambda.

The JWT populate lambda will only be called if the authorization code grant is completed and an access token is generated, but you should be doing that in your application.

So what it looks like is:

user visits your application user clicks 'login' user clicks 'login with OIDC' user authenticates user returned to FusionAuth reconcile lambda runs, setting values on user.data user object is created JWT populate lambda runs, pulling values from user.data and calling FusionAuth APIs to add user to a group or grant them permissions on an entity user object is updated, user exists in FusionAuth

Yes. You can do this with the API:

curl -H 'Authorization: ...' https://yourinstance.fusionauth.io/api/webauthn\?userId=00000000-0000-0000-0000-000000000001 > out

Then remove the following:

id insertInstant lastUsedInstant tenantId

update the userId

And use the import call:

curl -H 'X-FusionAuth-TenantId: newtenantid' -H 'Authorization: ...' https://yourinstance.fusionauth.io/api/webauthn/import -H 'Content-type:application/json' -d '{...}'

Right now you cannot turn off CAPTCHA for certain applications to handle this use case.

There's an open GH issue to address this. Please upvote or share your use case on there if you have thoughts.

As of writing, there is no direct support for push notifications as an MFA method in FusionAuth. If you would like such support, please open a feature request with more details about your use case.

However, you should be able to build something that sends a code via a push notification. Here's how to do that. (This requires a Starter, Essentials or Enterprise plan.)

This illustrates how to do this using the hosted login pages; if you use the APIs, it's a slightly different workflow, as outlined in the MFA guide.

configure FusionAuth to require a phone number when the user registers set up your android or ios device to send back the device id when the app is installed tie the device id to the user's phone number in your backend system set up a generic messenger. The messenger will send a phone number and a message when an MFA challenge occurs. look up the device id from the phone number in your system use the appropriate service to send a push notification with the code have the user enter the code in the MFA challenge screen