Hiya,

There are currently no plans to support the full mTLS spec. We are discussion 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., US 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.

@kiouplidis, can you please give us a little more detail on how you are set up and exactly what you are trying to do. I see you are getting a NetworkError when trying to reach (auth.*.com). Is that an instance of FusionAuth hosted by FusionAuth or is that an instance of FusionAuth that you have deployed? How are you trying to access the resource? Through a web browser or are you trying to execute an API call? The more information you can provide, the easier it will be to help.

If you have a paid plan which includes technical support, please open a ticket via your account portal.

@john-spellman can you tell us a little more about your set up and situation? Was it working before? What changed? Can the one user still log into prod? The more detail you give the easier it will be for someone to help. Please do not post any passwords or secrets.

@laurent-bartet awesome! So it sounds like you had things set up right, you just were not logged out, so when you went back the reconcile event never took place cause you were already logged in. Is that right?

@arnel-terblanche Can you tell us a little more about your setup? Is this a first time install? Was it working before? Is this a docker image you are trying to run? Please provide more details.

@mark-robustelli

Hello, sorry for away from this topic for a week due to my other ad hoc job,

I've already solved this topic, it's not about setting on Fusionauth or google credential.

but it's because I used google's client id on Fusionauth callback and
after you told me to set applicationId in my Fusionauth admin then I used ApplicationId on google oauth's callback.

that's why it kept return me client id is invalid.

it was right under my nose, but I couldn't see it.

Thank you for reply me, that's very helpful, It would take more time if you didn't help me.

@joseantonio When you add the response_type=code. That should be literal 'response_type=code' not response_type={code} where {code} is some secret. Other than that, you can add additional parameters to the query string if needed. As long as you are not passing secrets in the query string you should be ok.

@cybermark0707 That is a bit of a loaded question. If you have something more specific in mind, please let me know but the following should be a good start.

Overall:
Getting Started

If you are a developer and want to get hands on with an example, check out:
Quickstarts

@hamza-chouaibi said in FusionAuth setting wrong domain the the cookie io games:

I am using custom local domains.

https://auth.domain.test <= FusionAuth
https://app.domain.test <= Angular app

I also tried FusionAuth at https://auth.app.domain.test but I still get the same issue and chrome block the cookie.

I am getting issue with cookies, the domain on cookies is test.

Example: app.at_exp=1742980022; Domain=test; Max-Age=3599; Path=/; SameSite=Lax; Secure

Any idea why we endup wuth Domain=test ?

The SameSite=Lax attribute restricts the cookie from being sent with cross-site requests. If your application is making requests across subdomains, you may need to adjust this setting to SameSite=None; Secure for cross-origin requests.

Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

@yuriy-barvenko Ok, I'm in the same boat, but I think it is most likely the database back-end. Reason being, I migrated our database from the docker instance to a stand alone instance of PostgreSQL and I immediately noticed some performance degradation.

I'm running version 1.55.1 of FusionAuth and PostgreSQL version 14. There are documented performance improvements in both FusionAuth and PostgreSQL. I'll be updating my version of PostgreSQL and will report back.

@dev I am not sure you can set that level of debugging in FusionAuth. You can change logging in the AdminUI for various things like Lambdas, CORS filter, and that sort of thing.

@mark-robustelli Before I move to this activity, I wanted to share an observation that I made just now

So turns out that the error that I posted doesn't turn up every time I open up one of those pages

It occurs when I open those pages consecutively and the CPU spikes to the "requests" range

So to give you an example:

Click on Users -> Takes around 20s to load -> CPU Spike observed but within request range -> No error in container logs

Click on Users -> Immediately click on Reports/Login -> Move to Reports/Registration -> CPU spikes above request range -> Error in Container logs

So could this be a performance tuning issue?

As for your query about the config

Users: 7061
Applications: 6700
Tenants: 8200

Fusionauth is running on GKE on an n2d-standard-8 (8 vCPU, 32 GB RAM) nodepool, I've already mentioned the resources allocated to the deployment via the helmchart in the original thread message^

@mark-robustelli

It's possible, I didn't really keep track of that per se

We eventually moved on from this version and jumped to 1.40.x and surprisingly there were no issues in that version so this post can be closed

That being said, I did face a similar issue in a newer version for which I might post another thread

Hello @cristian
I am kind if facing the same issue here, how did you go about solving it?

@mark-robustelli No worries, we do have a working setup now after a slew of theme tweaks. That said there is still an outstanding question and a possible bug (both low priority).

The question: What happened to the ability to complete an oauth authentication flow by POSTing a code to /oauth2/passwordless? That worked in 1.48.3 but not in 1.55.1.

The potential bug: Why does a GET call to /oauth2/passwordless/<invalid code> redirect the user to the browser confirmation page (even when the request is from the same browser) instead of an invalid code page?

@aditya-badayalya glad you got it working.

@maciej-wisniowski Looks like you are getting some traction on the issue. Thanks for taking the time to work through this and submit the issue to make FusionAuth better.

1. User Linking Issues Between SP & IdP-Initiated Logins

No, this behavior is not expected—you should not need to drop and re-link users every time they switch login methods.

Troubleshooting Steps:

Are these configured as two separate Identity Providers in FusionAuth? If so, ensure they are both linked to the same FusionAuth user. If they are separate, FusionAuth may be treating them as different authentication sources, causing conflicts. Is Azure using the same application for both login flows? If different applications are used in Azure, they may be sending different user identifiers to FusionAuth. Enable Debug Logging in FusionAuth: Go to System > Event Log and enable Debug Mode in the Identity Provider settings. Compare the SAML attributes (claims) being sent in SP vs. IdP-initiated logins. If they differ, you may need to adjust Azure’s claim mappings to ensure consistency.

2. Ensuring Correct Redirect URL in IdP-Initiated Flow

Yes, RelayState works in FusionAuth, but there are specific requirements:

Check Your FusionAuth Version

RelayState support was added in FusionAuth 1.41.0+. If you are on an older version, FusionAuth will default to the first redirect URL in the list.

Correct RelayState Configuration

Ensure the target redirect URL is listed as an "Authorized Redirect URL" in the FusionAuth application settings. URL-encode the redirect URL before appending it to RelayState. Example: https://example.com/welcome → https%3A%2F%2Fexample.com%2Fwelcome Append the encoded URL to the ACS URL in Azure.

Example ACS URL with RelayState:

https://your-fusionauth-instance/samlv2/acs?RelayState=https%3A%2F%2Fexample.com%2Fwelcome Test by logging in via IdP-initiated flow and checking if FusionAuth respects the RelayState.

Additional References:

SAML Redirects in FusionAuth IdP-Initiated SAML Login

Summary:

User linking issues are likely caused by different SAML claims or separate Identity Provider configurations in FusionAuth. Enable debugging to check for mismatched attributes. RelayState should work in IdP-initiated logins if you are on FusionAuth 1.41.0+, URL-encode the redirect URL, and ensure it is allowed in the application's settings.

This behavior is due to FusionAuth’s default settings for email templates. The Magic Link URL is template-driven, and by default, it may reference a local development environment unless explicitly configured.

How to Fix This:

Customize the Magic Link URL in Email Templates

FusionAuth allows you to update the email template directly. You may want to use the FusionAuth CLI and version control to manage email templates. Refer to the note in this documentation for details:
Email Templates & Replacement Variables

Update the Tenant Configuration

If you want to avoid changes to the email templates, you can put the link in the tenant object and have your template pull from there. To ensure Magic Links point to the correct domain (auth.example.com), update your tenant’s data object using the Tenant API:
Update a Tenant API This API allows you to populate the tenant.data object. Then you can use it in your email templates.

Summary

Magic Links use email templates, which may default to localhost:9011. Updating tenant settings allows you to set the correct domain dynamically. Use the Tenant API to configure the Magic Link domain properly.