FusionAuth
login.success not fired on registration event
Description
Enabling self service registration a user is logged in after. We do not transmit a login.success event. Perhaps we should.
Observed versions
1.51.2
Affects versions
The version, or versions where this bug exists. If you do not know, please leave blank for now.
Steps to reproduce
Steps to reproduce the behavior:
- Have a
login.successwebhook be required to succeed on all webhooks - Have your webhook return a
non-200 - Enable Self Service Registration
- Register a user
- See that the user is able to login after the registration event.
Expected behavior
We should not log a user in after registration or fire a webhook (login.success) after the registration event
Screenshots
If applicable, add screenshots to help explain your problem. Delete this section if it is not applicable.
Platform
(Please complete the following information)
- Device: [e.g. Desktop, iPhone X, Pixel 3, etc]
- OS: [e.g. iOS, macOS, Windows ME]
- Browser + version [e.g. chrome, safari plus a version]
- Database [MySQL | PostgresSQL] & and version
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
Additional context
Add any other context about the problem here.
I'm not sure exactly what you're asking for.
When you register a user we send :
user.createuser.create.completeuser.registration.createuser.registration.create.completed
We do not send:
user.login.success
Do you think we should be sending user.login during the User / Registration create workflow?
Events are sent by the API. The SSO / Self-Service workflows are an app built on top of the API. So in that sense they are de-coupled, and if the user is logged into the SSO after a successful registration, this is the choice of SSO / Self-Service registration workflow.
This isn't to say we can't change any of this, but the registration flow in theory should not know how SSO is implemented. Now, if the User Registration or User Create APIs send back a JWT that could be used for authentication, perhaps that means these APIs should send a user.login.success event?
If we did that, we'd likely need to add additional meta-data to the event to indicate the user didn't actually login, but we created a JWT as a result of creating the user, or a new registration.
If the customer is using self-service registration, they may always want to be listening for user.create or user.registration events.
Do you think we should be sending user.login during the User / Registration create workflow?
Yes, if we consider every time a JWT is made as a "login". You could argue that if I failed this user.login.success webhook TX, then I would expect that every dependent process would not allow a JWT to be made (or any other type of authorization "artifact").
If we did that, we'd likely need to add additional meta-data to the event to indicate the user didn't actually login, but we created a JWT as a result of creating the user, or a new registration.
Agree
If the customer is using self-service registration, they may always want to be listening for user.create or user.registration events.
Yes, their could be an edge case where you want to allow the registration but block the minting of a JWT/AT by keying off of the user.login.success TX. Currently you cannot do this. Yo have to block the registration (registration.create) to prevent the JWT from being minted in the registration process.
We could also have something like user.access.create as a webhook to encapsulate this type of JWT creation as part of the registration or user create workflow. Failing this event, would prevent an auth code, saml response, or AT from being made. Thinking aloud, on that last part.
@robotdan
The intent of user.login.success is to indicate that a user was presented with a credential challenge and that they passed it. Likewise, user.login.failed indicates that the challenge was presented and the user didn't pass it. Because during registration the user is creating the credential, there is no challenge and therefore no success or failure.
If the user submitted an invalid password during registration, or they didn't provide all required user data during registration, we wouldn't want to call that a login failure and fire the user.login.failed event. Similarly, we don't fire user.login.success on a successful registration.
But I understand the desire to have both notions captured by the same event. My guess is that we won't change this behavior anytime soon and we should encourage users to also capture user.registration.create.complete events, knowing that a session has been established at that point.
Related issues:
- https://github.com/FusionAuth/fusionauth-issues/issues/731
I like this approach:
We could also have something like user.access.create as a webhook to encapsulate this type of JWT creation as part of the registration or user create workflow. Failing this event, would prevent an auth code, saml response, or AT from being made. Thinking aloud, on that last part.
We could fire a jwt.accessToken.created event every time an access token was generated, whatever the method (registration, user creation, user login, vend API). It could be high traffic, but I could see it being useful for tracking all kinds of logins.
This is probably a separate, related issue. If you think it achieves what the requester was trying to achieve, @jobannon , happy to open a tracking issue.
