Nope, there's no way to know when passwordless logins have expired via webhook.

You have a couple of options:

You can create a github issue specifying your use case. I'm not sure how quickly this feature would be implemented, however, as this is the first request I've seen. You could note when you send the passwordless login on the user object (in user.data) and build a query that shows all the users with expired passwordless logins. You can know when you sent it and how long it is good for by querying the tenant settings, which gives you the time it expires. You could note when you send the passwordless login in some other external database and process it there.

Added a doc bug: https://github.com/fusionauth/fusionauth-issues/issues/1005

Hiya,

Can you please provide more details:

any logs (esp with debug enabled) what version of FusionAuth are you running? configuration of the SAML provider, including everything outlined here: https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/ what docs you used on the okta side

I know we have customers who have succeeded in using Okta as the Idp and FusionAuth as the SP, so would love to get to the bottom of this.

Hiya,

Do you have a script or set of scripts which illustrates a valid user enumeration attack against FusionAuth?

I did a test of three kinds of user login:

existing user, valid password existing user, invalid password user who didn't exist

And they all returned in roughly the same amount of time.

Works perfectly now. TY!

On reading through your linked document, FusionAuth doesn't support this natively. There's no 'sso' endpoint which does what the docs say must be done (checking the signature, creating the new payload, etc...).

You have a couple of options:

file a feature request: https://github.com/fusionauth/fusionauth-issues/issues explaining what you'd like to have done use OIDC for discourse (which should work with FusionAuth out of the box): https://meta.discourse.org/t/openid-connect-authentication-plugin/103632 set up a small proxy server which would receive the SSO request from discourse, present a login screen, and call the FusionAuth Login API to authenticate the user

I'd probably recommend the OIDC route unless there's some reason why it wouldn't work for you.

Solved. The error code coming back is [duplicate]user.email. I just need to ignore that!

Yup, you got it!

And also HMAC keys will never be displayed in the public-key list. Since they are symmetric, displaying them in that list would let anyone viewing them sign JWTs indistinguishable from those signed by FusionAuth.

Should I be working with the email template or is that for something else?

I'd look at email templates and tweaking those, yes. https://fusionauth.io/docs/v1/tech/email-templates/email-templates/ has some docs about this.

Is a client_id and a user_id (returned from registration) the same thing?

Nope. client_id represents an application in FusionAuth. user_id represents a user.

Hope that helps, glad you're getting close!

Sure, you want to use the patch identity provider method: https://github.com/FusionAuth/fusionauth-java-client/blob/master/src/main/java/io/fusionauth/client/FusionAuthClient.java#L1575

You'll want to update the application configuration section: https://fusionauth.io/docs/v1/tech/apis/identity-providers/

Be aware that there is an open issue regarding this: https://github.com/FusionAuth/fusionauth-issues/issues/767 If this affects you, please upvote it so that it moves up in our priority list.

This also may be worth reading: https://fusionauth.io/community/forum/topic/510/update-identity-provider

Ok, I've created a feature request.

Hi @richb201 ,

Are you asking what the security implications are for not using passwords at all?

That's hard to give general guidance on, as that depends on how good users are at keeping their email accounts safe.

In general it's going to be pretty good because people tend to care more about their email accounts and pay more attention to them than some random account they signed up for 6 months ago and haven't checked since.

Also in favor of this is the fact that the passwordless codes are time limited (configurable in the tenant).

But, as I'm sure you can understand, I can't do a thorough security analysis because I don't know the full details of your scenario.

Nope, this is the recommended solution.

If you think there's a valid use case for having this be supported natively (without the webhook), please file an issue with a feature request, including as many details as you can: https://github.com/fusionauth/fusionauth-issues/issues

Ah, I see how that could be confusing. Sorry about that. Glad you got it sorted out and it works!

We just did some testing and it appears that JFrog Artifactory can now use FusionAuth as a SAML ID Provider.

Thanks again for the quick work on this issue.

Tom M

'Tis I indeed! Continuing my signature moves of knowing juuuuuust enough to be dangerous to myself and others LOL. I'm checking the settings now, thanks to you and Dan for the support!