login.success not fired on registration event

[jobannon]

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.success webhook 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.

[robotdan]

I'm not sure exactly what you're asking for.

When you register a user we send :

• user.create
• user.create.complete
• user.registration.create
• user.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.

[jobannon]

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, I am not sure if this make sense.

@robotdan