As of 1.59.0 this is possible but it is slightly unintuitive how to do it. It’s entirely driven by the form being used. Here's how to do it:

• create a new user admin form: https://fusionauth.io/docs/lifecycle/manage-users/admin-forms
• make sure you omit the 'password' field from the form
• assign the form to your tenant
• create a new user

You can also create a user directly via the API with no password.

This functionality is now present in FusionAuth as of 1.59.0.

https://github.com/FusionAuth/fusionauth-issues/issues/484 is the tracking issue.

Yes, I believe so.

It appears that connecting MitID to an application (also called an SP) requires utilizing an approved broker. A broker is essentially an OIDC connector.

Here is a list of official brokers: https://www.mitid.dk/en-gb/broker/current-brokers/.

We haven’t tested this, but based on reviewing Signicat’s OIDC documentation, the process seems fairly straightforward. They are one of the MitID brokers.

Does FusionAuth support MitID which is a national digital id for Denmark?

You can create two values for the FusionAuth url:

internalFusionAuthURL="http://fusionauth:9011"
externalFusionAuthURL="http://localhost:9011"

So basically whenever you are sending the redirect to the browser (pretty much just the authorize and logout URLs) you use externalFusionAuthURL which references localhost.

When you are communicating with FusionAuth from the application backend (the express app) you use the internalFusionAuthURL which references the docker domain name.

I tested that out and it seems to work fine.

Give that a try.

Hiya,

I want to run FusionAuth and the backend app in Docker, but run into an issue with this quickstart: https://github.com/FusionAuth/fusionauth-quickstart-javascript-express-web/

When I modify the complete-application/.env file to have the value for fusionAuthURL=http://localhost:9011 the token exchange fails (because the dockerized express app doesn't know how to get to FusionAuth).

When I set fusionAuthURL=http://fusionauth:9011 where fusionauth is the internal docker network domain name of the FusionAuth server, the initial redirect fails, because my browser doesn't know about that domain (not being in Docker).

How can I fix this?

Worth re-emphasizing that this voids any warranty you might have from FusionAuth, per the license, exhibit A section 5.1.

You can't get support from FusionAuth if you modify the software.

Yes. You can use FusionAuth's OpenID Connect Identity Provider.

I did this a few weeks ago, so am writing these instructions from memory.

Prerequisites:

• A yahoo account
• A running FusionAuth instance (localhost is fine)

Steps:

• Go to the Yahoo! developer network and create an app.
• The redirect URI for Yahoo is https://<your instance>/oauth2/callback
• Save off the provided Client ID (Consumer Key) and Client Secret (Consumer Secret).
• Then go to FusionAuth and create an OpenID Connect Identity Provider: <your instance>/admin/identity-provider/add/OpenIDConnect
• Put the Client ID (Consumer Key) and Client Secret (Consumer Secret) into the Client Id and Client secret fields, respectively.
• Uncheck Discover Endpoints. Manually configure the endpoints:
  • Set the Authorization Endpoint to https://api.login.yahoo.com/oauth2/request_auth
  • Set the Token Endpoint to https://api.login.yahoo.com/oauth2/get_token
  • Set the Userinfo Endpoint to https://api.login.yahoo.com/openid/v1/userinfo
• Set the Scope to openid email profile and any other scopes you might need. (I was unable to find an authoritative list, but here's info about the mail scopes.)
• Update the Button text and Button image as needed.
• Enable it for applications as needed.
• Save the Identity Provider.

I'd like to off a "Login with Yahoo!" button. Can I use FusionAuth to do so?

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.