@dan Thank you for your support. Fixing the signature just saved me another couple of hours (also coming from https://fusionauth.io/blog/2020/07/14/django-and-oauth/) ^^

The JWT TTL can be configured per application, so if you were using a different application for OIDC vs an API - then you could do it.

But if you don't want to use multiple applications, then it is not possible, at least currently.

I could see a use case for asking for a JWT with a TTL equal to or less than the configuration and that request being honored, that could be a feature request. But as of right now, the only option is different applications.

You can put whatever you want in the theme pages, but it's a good idea to keep them lean so the user has a quick login experience. After all, most folks don't care about auth except when it doesn't work!

You can optionally pass info in the state parameter, that will come back to the caller. This can be encoded JSON, as long as it is url safe. You will want to make sure that you don't put too much stuff in there, as there are URL length limits for browsers (though I learned that chrome has a URL size limit of 2MB!). Here's an example of using the state parameter for application state.

Or if you have different applications and redirect URLs, then just gathering metrics on the URLs may give you insight into who is using login, and from where.

Sort of depends upon what type of analytics you need.

Hiya,

I think this is what you are looking for:

https://fusionauth.io/docs/v1/tech/apis/identity-providers/openid-connect/#complete-an-openid-connect-login

So you aren't so much starting the OIDC flow as finishing it. This would be if you were building your own login form.

Another alternative that I think does what you want is to provide an idp_hint parameter, which will direct the user right to the correct login form, without requiring an additional click: https://fusionauth.io/docs/v1/tech/identity-providers/#hints On a re-read of your question, I think that's what you're looking for.

If I misunderstand your question, please let me know.

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.

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