@dan Thanks so much for the followup! For now, I'll work around the issue with a read/merge/write on the client.

@trevorr Ok, I think I found the cause: the Privacy Badger extension. Not sure if it's fixable or worth fixing.

Posting here in addition to GitHub: The issue for me was that the signing key didn't have the right Apple-provided key identifier, which goes in the kid field of the client_secret JWT header. Recreating the private key with that identifier fixed the issue.

It looks like setting the email address in a lambda works for Facebook now (as of at least 1.41.2):

  if (!facebookUser.email) {
    user.email = facebookUser.id + '@no-email.facebook.com';
  }

1/10/2023 10:10:33 PM Z Linking strategy [LinkByEmail]
1/10/2023 10:10:33 PM Z Resolved email to []
1/10/2023 10:10:33 PM Z Resolved username to [null]
1/10/2023 10:10:33 PM Z Resolved unique Id to [115587478085870]
1/10/2023 10:10:33 PM Z Identity provider returned a unique Id [115587478085870].
1/10/2023 10:10:33 PM Z A link has not yet been established for this external user.
1/10/2023 10:10:33 PM Z The user with the email address [] does not exist.
1/10/2023 10:10:33 PM Z Invoke configured lambda with Id [787cd34e-1618-4cd9-8156-936734cfe368]
1/10/2023 10:10:33 PM Z The lambda set or modified the initially resolved email. Email is now [115587478085870@no-email.facebook.com]
1/10/2023 10:10:33 PM Z Creating user: 
1/10/2023 10:10:33 PM Z User is not registered for application with Id [e0da3f10-7efa-4a6b-95f8-fbf4894884b5]
1/10/2023 10:10:33 PM Z User has successfully been reconciled and logged into FusionAuth.
1/10/2023 10:10:33 PM Z Authentication type: FACEBOOK
1/10/2023 10:10:33 PM Z Authentication state: Authenticated

It appears I was running an old version locally (1.30.2). This issue has been fixed as of at least 1.41.2.

It looks like setting the email address in a lambda works for Facebook now (as of at least 1.41.2):

  if (!facebookUser.email) {
    user.email = facebookUser.id + '@no-email.facebook.com';
  }

1/10/2023 10:10:33 PM Z Linking strategy [LinkByEmail]
1/10/2023 10:10:33 PM Z Resolved email to []
1/10/2023 10:10:33 PM Z Resolved username to [null]
1/10/2023 10:10:33 PM Z Resolved unique Id to [115587478085870]
1/10/2023 10:10:33 PM Z Identity provider returned a unique Id [115587478085870].
1/10/2023 10:10:33 PM Z A link has not yet been established for this external user.
1/10/2023 10:10:33 PM Z The user with the email address [] does not exist.
1/10/2023 10:10:33 PM Z Invoke configured lambda with Id [787cd34e-1618-4cd9-8156-936734cfe368]
1/10/2023 10:10:33 PM Z The lambda set or modified the initially resolved email. Email is now [115587478085870@no-email.facebook.com]
1/10/2023 10:10:33 PM Z Creating user: 
1/10/2023 10:10:33 PM Z User is not registered for application with Id [e0da3f10-7efa-4a6b-95f8-fbf4894884b5]
1/10/2023 10:10:33 PM Z User has successfully been reconciled and logged into FusionAuth.
1/10/2023 10:10:33 PM Z Authentication type: FACEBOOK
1/10/2023 10:10:33 PM Z Authentication state: Authenticated

It appears I was running an old version locally (1.30.2). This issue has been fixed as of at least 1.41.2.

It appears to happen with Facebook too:

https://www.facebook.com/v3.1/dialog/oauth?client_id=465092324593769&redirect_uri=https%3A%2F%2Fauth.local.fittfinder.com%3A9443%3A9443%2Foauth2%2Fcallback&response_type=code&scope=email%2Cpublic_profile&state=...

When testing locally with FusionAuth behind a TLS proxy on port 9443, the Google IdP seems to be duplicating the port number, which causes login to fail:

Error 400: invalid_request
Request details: redirect_uri=https://auth.local.fittfinder.com:9443:9443/oauth2/callback

That port duplication seems to be generated by FusionAuth during this redirect:

GET https://auth.local.fittfinder.com:9443/oauth2/redirect?client_id=e0da3f10-7efa-4a6b-95f8-fbf4894884b5&identityProviderId=82339786-3dff-42a6-aac6-1f1ceecb6c46&state=...
Status: 302 Found
Location: https://accounts.google.com/o/oauth2/v2/auth?client_id=991204729861-83kivvrh7odv9b0mbf0qnrd6bvd5p6gm.apps.googleusercontent.com&redirect_uri=https%3A%2F%2Fauth.local.fittfinder.com%3A9443%3A9443%2Foauth2%2Fcallback&response_type=code&scope=email+profile+openid&state=...

Note the %3A9443%3A9443 in the redirect_uri. Is this a FusionAuth bug?

@dan Thanks!

For some reason, Google doesn't show either of those pages for "fusionauth password change revoke refresh token". However, it does now show this one, so hopefully that will help others.

I got the "re-login after password change" approach working pretty easily, so I'll stick with that for now for tighter security, but it's good to know I can turn that off if necessary.

If possible in the future, it would be great to be able to control that per-password change. It's the right behavior for changing a potentially compromised password, but not for setting an initial password. Of course, my app could also revoke the refresh tokens explicitly.

I can't find it documented anywhere, but changing a user's password seems to delete all of their sessions. This makes sense, but is there a way to change the password while keeping the user logged in?

Details: I initially create users with a random and immediately forgotten password (since password is a required field), and have them log in the first time with a passwordless login code I email them. Once they're logged in, I allow them to set their initial password via my application server, which uses PATCH /api/user/{userId} with an API key. This seems to invalidate the user's refresh token, which I'd like to avoid. Perhaps there's a way to change the user's password with their own access token that doesn't delete that session? Alternatively, I could have the server perform a login using the new password and return new tokens, but it would be nice to avoid that complexity.

We'd like to have passwordless codes that can be used more than once. For example, when a new user signs up by providing an email address, we send a passwordless link in an email to authenticate the user and let them set a password and complete the signup. If they click the link but then decide they want to come back later, we want the email link to continue working (at least until the code expires). Is this currently possible or feasible to add as an option?

Note that we don't use the FusionAuth email verification/set password email because a) we want to send email from our marketing platform for consistent tracking, b) we want a consistent look and feel in the password setting UI (simulating Material UI in a FA theme seems infeasible), and c) FusionAuth doesn't seem to have a way to send the user into our app after they set a password.

@trevorr Ok, I think I found the cause: the Privacy Badger extension. Not sure if it's fixable or worth fixing.

I'm trying to get Google login to work with the latest FusionAuth (1.26.1) and Chrome (90.0.4430.93). In 2 out of 3 profiles, it works fine: A window pops up to authorize the app, I click okay, the FusionAuth login form dims and shows a spinning icon, and then it redirects to my app.

In the third profile, the first two things happen but the last two don't. If I click Login with Google again, the Google-hosted window pops up for a second then immediately closes, but FusionAuth again does nothing more (no dimming or spinning icon). Nothing in the console, nothing in the FusionAuth event log (IdP debug is enabled). The only thing that happens is a POST to https://play.google.com/log?format=json&hasfast=true&authuser=0. Any ideas on how to debug this?

Posting here in addition to GitHub: The issue for me was that the signing key didn't have the right Apple-provided key identifier, which goes in the kid field of the client_secret JWT header. Recreating the private key with that identifier fixed the issue.