If you want to add or remove a registration from a user (registrations are how a user is authorized to use an application) you could either allow someone to use the FusionAuth admin screen (possibly with a limited role) or you could use the API to build your own more limited interface.

Here's the API call you would want for this specific use case: https://fusionauth.io/docs/v1/tech/apis/registrations#delete-a-user-registration

There is no supported client library for Delphi.

I'm also not aware of any community supported client library for Delphi.

But here is a post indicating that someone built at least pieces of an integration layer. I'd suggest reaching out to John Kouraklis and seeing if they have any code to share.

It looks like multi match (at least as of 2019) doesn't support wildcards:

[a] multimatch query requires match queries as its internal queries. And a match query doesn't support wildcards.

https://discuss.elastic.co/t/query-with-multimatch-and-wildcard/189962

Can you try with a non wildcard query?

Heya,

JWTs are stateless tokens of identities. If you want a JWT to be revoked after someone has logged out from FusionAuth, you need to tie state back in.

See this article for various options for revoking JWTs: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts

This is possible. Doing so allows you to weave passwordless into the normal OAuth flow so you can use standard OAuth libraries but not have your user enter a password.

Start the passwordless login on the server side (using the API). Get the passwordless code. Send this url to the client: [FusionAuthURL]/oauth2/passwordless/[passwordlesscode]?redirect_uri=[redirect URI]&response_type=code&client_id=[client_id]. Have the client request this url. It'll be just as if the user had authenticated via the /oauth2/authorize endpoint and the user had entered their credentials. You'll get back an authorization code which can then be exchanged for an access token/JWT.

If you navigate to the Tenant configuration and view the password tab, you should see it as an option in the encryption scheme section.

You can also view the logs during startup and confirm it was registered.

I'm not sure I understand your question. I'd use OIDC for the login form, but the whole point of OAuth (at least the authorization code grant) is that the login process happens at a third party (FusionAuth in this instance).

If you want to have the user login and control the whole process (including your own pages), use the login API, or, if you must use an OAuth grant, the password grant.

Please feel free to give more information about your question, as again, I'm not sure I understood it.

Great to hear!

This iss possible and we have many other customers doing this.

Technically speaking FusionAuth doesn't care what kind of proxy sits in front of it, if any. So this is outside of FusionAuth but Cloudflare makes it really simple.

You have two main options.

The first is FusionAuth cloud, which is a managed service. You can learn more about that here. Note that hosting is entirely separate and orthogonal to the paid editions.

The second is to host it yourself, in your environment.

We don't support this currently. If you have a use case that this would be helpful for, please file a GitHub issue explaining what you are looking for.

It is sorta possible to create a user with a randomly generated email and password. So if you wanted to allow people to sign up, you could generate this user, and then send them/present login details, and then the user could be anonymous but still have a profile.

We handle all of this and you can use the native UIs for each of these when on mobile. This is all handled automatically by Facebook, Google, Apple and others.

More about external login providers.

We have Breached Password Detection (in the paid edition) as well as brute-force login detection.

We have some other related features on the roadmap for 2020.

The mobile app really shouldn’t be calling FusionAuth APIs. You should be using your backend to call FusionAuth. Usually, this is a proxy style setup, as outlined in this post about OAuth and React. This will work for both OAuth and regular API calls.

If you really want the mobile app to call the OAuth flow directly, make sure you follow the best practices from RFC 8252 (use the browser, not an embedded webview). Here's a React Native tutorial that you can adapt.

This depends on how the JWT was signs, but is probably fine, especially if JWTs are only used in APIs. It's very typical to want to ensure that existing JWTs are accepted as long as they haven’t expired. You'll also need to ensure that new JWTs from FusionAuth are also accepted.

So this is really a question of making sure the JWT producers and consumers have the correct signing secrets.

You can solve this by sharing the secrets between the old system and FusionAuth (check out the Keymaster to import existing keys or making sure your clients can look up the keys from a JWKS endpoint from both the old and the new system.

You can use Connectors to integrate with your old backend but this isn’t the best approach.

The best approach is to do a migration all in one step using our Import API.

If you are worried about resetting your users' passwords (justifiably!), you can implement custom password hashing if needed so that no one would need to do a password reset. See password encryptors for more info. If you use this path, you can upgrade each user's old password hash to BCrypt as users log in.

Hiya,

You may change your edition of FusionAuth from your account page: https://account.fusionauth.io/account/

It looks like you are currently on the Community edition which is is free. If you want to delete your FusionAuth cloud installation, you can do so in the Deployments section.

You should be able to edit the birth date of users in the admin UI.

Just go to the user details screen, click the 'edit user' button in the upper right hand corner, then go to the 'options' section and add in the user's birthdate. Note the format is "month/day/year".

Click save and the birthdate should be set.

Hiya,

It seems you are asking how to allow a user to use MFA at all times, except when they are changing their password. That would seem to me to be exactly the right time to require MFA, but maybe I'm missing something.

The 242 return code is documented here.

If you are determined to avoid TOTP when someone is changing their password, you could write your own password change page and turn off MFA for the user when you notice they are changing their password. Then, once they've succeeded, you could turn it on again.

Hope that helps.