Posts made by trevorr

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.

I'm having the same issue. My event log with IdP debug enabled looks like @progressman showed:

Apple IdP Response Debug Log

5/2/2021 12:06:17 AM GMT Validate the provided [id_token] value [ey...]
5/2/2021 12:06:17 AM GMT Decode the [id_token].
5/2/2021 12:06:17 AM GMT Assert the [iss] claim is equal to [https://appleid.apple.com].
5/2/2021 12:06:17 AM GMT Assert the [aud] claim is equal to [com.fittfinder.app].
5/2/2021 12:06:17 AM GMT Calculate the [c_hash] to ensure the integrity of the provided [code] value [cb...].
5/2/2021 12:06:17 AM GMT Generate the [client_secret] used to call the configured Token endpoint.
5/2/2021 12:06:17 AM GMT Call the configured Token endpoint [https://appleid.apple.com/auth/token] with the the following [client_secret] value:
ey...
5/2/2021 12:06:18 AM GMT Endpoint returned status code [400]
5/2/2021 12:06:18 AM GMT The response was not successful, see the error event log.

Request to the [https://appleid.apple.com/auth/token] endpoint failed. Status code [400].

Error response is 
{
  "error" : "invalid_client"
}

I tried with 2 different Apple IDs (my developer account and an unrelated one). No leading/trailing whitespace on my Services ID or Team ID. Using Default Apple Reconcile lambda. I've only seen this specific error mentioned in this post and this issue: https://github.com/FusionAuth/fusionauth-issues/issues/885

Thanks for the quick response, Dan!

That's somewhat confusing though, right? It seems like everyone is trying to get rid of passwords these days, and FA has such great support for external IdP's now. Also, it would be useful to know whether a user has a password set, and therefore whether that login method is available. (To be clear, no password would mean no ability to log in directly, not that the password is blank.) That could simplify security audits. Would changing this be a reasonable feature request?

Note that the random password example in that other thread might fail sporadically because there's no guarantee that a base-64 string will contain a "special character". That edge case is another motivation for not wanting the password to be required.

Is it possible to create a user that never has a password (and never gets emailed to create one)? I want to create users/registrations for users that will only authenticate using another IdP, such as SAML.

The documentation for POST /api/user says this about user.password:

This field is optional only if sendSetPasswordEmail is set to true. By default sendSetPasswordEmail is false, and then this field will be required.

I verified that this is enforced:

{
  "fieldErrors": {
    "user.password": [
      {
        "code": "[blank]user.password",
        "message": "You must specify the [user.password] property."
      }
    ]
  }
}

Thanks for the clarification. Is zero-downtime somewhere on the roadmap? It seems like it could be accomplished with a strict release process on both the FA/development and user/deployment sides. For example, schema changes are always compatible with the immediately previous version and users install every version consecutively; FA vN runs on schema vN+1, but not necessarily vN+2.

I ask because, while seconds aren't critical for most cases, there are cases where either they do matter or getting down to seconds requires non-trivial, hard-to-get-right automation. For instance, the untuned automation I'm using with ECS and ELB seems to run on the order of a minute or two, due to delays in starting containers and ELB health checks, during which I see 502 Bad Gateway errors.

Given that, I'm inclined to take the risk of not shutting down the old instance, and hoping that either the changed schema isn't used during that time window, or the affected features fail without data corruption. Of course, if you know specific reasons that this is dangerous, please let me know.

(It occurs to me that I'm also assuming the schema migration is transactional/atomic. That's at least possible in MySQL 8+ and Postgres, though I don't know if FA does it that way.)

Is it possible, either in general or between specific versions, to upgrade FusionAuth without downtime? I haven't been able to find any documentation specifically on production upgrades.

For instance, I currently deploy FA on AWS ECS, which attempts to deploy the new version and wait for a passing load-balancer health-check before draining and stopping the old version. How likely is it that the old version will start failing requests due to an incompatible schema change in the SQL or search database?

Would upgrading through consecutive versions help? In other words, is there any care given to avoiding a breaking change happening between adjacent versions?

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

I'm trying to update registration.data using PATCH against FA 1.15.8 according to this documentation: https://fusionauth.io/docs/v1/tech/apis/registrations#update-a-user-registration

The data is being updated, but the other optional fields that I didn't specify in the PATCH seem to be getting cleared. For example, I had originally set roles and timezone in the FA UI, but these were empty after the PATCH. Does PATCH merge the given registration object with the existing one? It seems like it should, since all but one property of this API is in that object, and PATCH wouldn't otherwise be useful.