Hiya @tim-0

I'm not sure I understand your flows. It sounds like you want to handle two use cases.

Use case #1 User is not in FusionAuth system, but is in the OIDC system. You want them to authenticate via the OIDC provider. Then they should register with FusionAuth. Then, going forward, they should authenticate against FusionAuth. Or maybe against the OIDC system too? Not clear.

Use case #2 User is in the FusionAuth system. They should still be verified against the OIDC system somehow but then shown a different page, no registration needed? After that, they'll auth against FusionAuth? I'm confused here because I don't know why they'd need to be verified against the OIDC system here.

Maybe it's worth taking a step back and explaining what you are trying to accomplish. Which system is going to be the system of record for the users. The OIDC system or FusionAuth? Do you have multiple applications in FusionAuth and the OIDC system only is used for one of them?

If you could lay out in detail the flow of the different user paths, I might be able to understand things a bit better.

Thanks!

There are two “worlds”, OAuth, and API only.

API world (JSON in body, proprietary to FusionAuth):

Application > Security > Login API Settings > Generate Refresh Tokens (Generate a a refresh token when using the Login API) Application > Security > Login API Settings > Enable JWT refresh (Allow a JWT to be refreshed using the /api/jwt/refresh API)

OAuth world (form params, in body and in request, standardized):

Application > OAuth > Generate Refresh Tokens (Generate a refresh token if offline_access scope was requested) Application > OAuth > Enabled Grants > Refresh Token (Allow a JWT to be refreshed using an refresh token) (edited)

If you are living in the OAuth world, then you can disable the API access, and just use the OAuth configuration. And vice versa.

For anyone else, the bug filed is here: https://github.com/FusionAuth/fusionauth-issues/issues/941

I think the simplest solution is to modify the link helper macro in the theme. This macro looks like this by default:

[#macro link url extraParameters=""] <a href="${url}?tenantId=${(tenantId)!''}&client_id=${(client_id?url)!''}&nonce=${(nonce?url)!''}&redirect_uri=${(redirect_uri?url)!''}&response_mode=${(response_mode?url)!''}&response_type=${(response_type?url)!''}&scope=${(scope?url)!''}&state=${(state?url)!''}&timezone=${(timezone?url)!''}&metaData.device.name=${(metaData.device.name?url)!''}&metaData.device.type=${(metaData.device.type?url)!''}${extraParameters!''}&code_challenge=${(code_challenge?url)!''}&code_challenge_method=${(code_challenge_method?url)!''}&user_code=${(user_code?url)!''}"> [#nested/] </a> [/#macro]

What we want to do is modify the redirect_uri in certain cases. In this case, we know that the url will have the value /password/forgot so we can put an if statement in there:

[#macro link url extraParameters=""] [#if url == "/password/forgot"] [#assign redirect_uri="https://example.com/pageb"] [/#if] ...

You'll also need to:

create the page that lives at url B (https://example.com/pageb in this example). It won't be hosted by FusionAuth. add url B to the list of Authorized Redirect URLs in your OAuth configuration.

That should work. There are some other alternatives, however. If you generate the "Forgot password" page without a client_id, you won't end up logged in after a password reset. Instead you'll end up at the "OAuth password complete" page, which you can design in the theme editor.

More about themes.

Hi, I have the same problem here. The tenant's SMTP setting are correct and test emails are successfully delivered. I'm evaluating the FusionAuth right now and often delete/re-register users with the same emails. Verification emails are delivered to all users but one. The only thing that distinguish the problem user from the others is the fact I initially registered him via Facebook identity provider, so his email was automatically verified. After that I deleted the user and trying to register with just email (not Facebook). And emails are not delivered. Manually sent SMTP test emails to that address also delivered successfully. I hope this help to investigate.

These are generated in the UI. So the values are not available from the API.

However you can derive them yourself as well. We just take the URL + /oauth2/authorize?... + redirect_uri etc.

Yea, that flexibility would be ideal IMO, although the registeredLogoutURLs should be workable for us at this point. FWIW that is actually the behavior I assumed before digging into the docs. I'll definitely add the issue to GitHub, as I think it's probably part of the path to getting OIDC Certification which appears to already have an issue.

Thanks!

From the user search docs, for the database search engine:

Regular expressions may not be used. A value of * will match all records.

For the elasticsearch search engine, you are limited to 10,000 records returned due to this bug: https://github.com/FusionAuth/fusionauth-issues/issues/494

Here's docs on how to switch between them: https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines

No hard limits, we have some clients running somewhere between 5-10k.

If you encounter any performance degradation, you can open a GitHub issue and we will take a look. We do have some work in plan to improve the UI for this type of scale.

I haven't implemented this identity provider myself, but from the documentation:

https://fusionauth.io/docs/v1/tech/identity-providers/facebook https://developers.facebook.com/docs/facebook-login/permissions/overview

It appears that 'permissions' are what facebook uses to mean 'scopes'. You ask for a permission of email or user_likes, for example.

Have you tried to put in the scope you want into the permissions field and tested it out?

For anyone reading this in the future, here's a list of the permissions that you can use: https://developers.facebook.com/docs/permissions/reference/

Note that it says:

Every permission below requires App Review, except: email, pages_show_list.

Hiya,

So here's what I did.

I made sure that email verification was enabled at the tenant level. "Tenants -> Your Tenant -> Email -> Email Verification Settings".

Then I ran the following curl scripts (where API_KEY is a valid FusionAuth API key) to mark the email of a user verified.

# create the user curl -XPOST -H'Content-type:application/json' -H "Authorization: $API_KEY" 'http://localhost:9011/api/user' -d '{"user" : { "email" : "testverify4@example.com" , "password" :"password", "verified" : false }}' # ask for a new verification id, but don't send the email--assume you send the email in some other way. curl -XPUT -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/verify-email?email=testverify4@example.com&sendVerifyEmail=false' # This sends back: # {"verificationId":"nBm3HvfI1fAgilLk2Hj06gXeYuidhRM25tPECtbpqMM"} # GET the user to make sure they still have email verified of false curl -XGET -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/552bdd9a-2655-433c-a91d-7002e730b385' # post to verify the user's email address curl -XPOST -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/verify-email/nBm3HvfI1fAgilLk2Hj06gXeYuidhRM25tPECtbpqMM' # GET the user to verify that the email address has been marked verified. curl -XGET -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/552bdd9a-2655-433c-a91d-7002e730b385'

Does this flow help?

Also, remember that there is registration email verification and user email verification, and the APIs are different. I believe, from what you wrote, that you are trying to get user email verification (that's the APIs you are using, except that the first post talks about verifying a registration); please correct me if I'm wrong.

They are globally unique, and they are deleted when a user is deleted. They must belong to a user.

The code is considered valid for n -1, n and n + 1 time steps. We use a 30s time step, so I think this would max out at 59s for a skew tolerance. In your case, if you have up to 70s of skew, this would plausibly break TOTP 2FA.

If you are on one of the editions that offer support with a guaranteed response time (more on those options here), the best way to file a ticket is to login to https://account.fusionauth.io and go to the support section. You'll see a way to submit a ticket, which will be routed to the appropriate team member.

The docker compose references the latest tag, but that tag is not dynamic, it is only the latest at a point in time.

To ensure you have the most recent latest tag - you can always run this command: docker pull fusionauth/fusionauth-app:latest

This is a common point of confusion, and there are lots of opinions on it as you might imagine. For your reading pleasure:

https://vsupalov.com/docker-latest-tag/
https://blog.container-solutions.com/docker-latest-confusion

Unfortunately the default tenant contains the FusionAuth application and so it cannot be deleted, short of dropping and recreating the entire FusionAuth database.

User ids need to be globally unique. You can either provide your own unique uuid or you can let FusionAuth provide them for you. But these values are not tenant scoped.

Ah, that's great! I've definitely made my share of mistakes, no worries!

Great. I've updated the documentation to reflect that google and facebook aren't supported; that'll be published next week. Sorry about that.

More details on the bug I filed above (and the doc change linked in the bug). If you try this with SAML/OIDC and it fails, please let me know.