[FR] Hooks for signup/login

[rafamel]

Hi there, excellent work!

I was thinking that in the same way we can currently set a passwordless endpoint to handle the token, it would be great if we could also define endpoints that ran on signup/login/logout/other actions.

This could be done either so the response from AuthN is independent of that endpoint response, or we could make the AuthN response fail too when the endpoint response does, which would also clear the path to (potentially) adding further data to the tokens, making #10 / #111 viable, while improving AuthN flexibility/possible use cases. With this flow, AuthN would pass the token data to the endpoint, which would in turn return the modified token data to be encrypted by AuthN and sent to the client.

It could also be used for custom email validations on signup, sending emails, adding custom rules for registration, et al.

What are your thoughts?

[cainlevy]

Yep! I'm noticing a pattern in requests for some kind of event bus. I think it would be a good extension point for AuthN, and could replace the webhooks that currently exist.

Do you have thoughts on what shape those events take or how they can integrate with a wide variety of systems?

[cainlevy]

@rafamel let's continue the discussion on #112

[cainlevy]

In response to #112 (comment):

Apologies for trying to merge this with an issue related to an event bus. Hooks are meaningfully different! I have a few points of caution here, so I'm looking to understand what new behavior they'll enable and be sure that hooks are the right way to address them.

My general concerns are:

1. Increased coupling between AuthN and the main app (or services).
2. Blocking on a synchronous API call. We'll need timeouts to guard against the increased latency. Would a failure cancel the user action?
3. Hooks that do more than halt the user action will need bespoke response data for each intended use case. This has the potential for scope creep and an increase in AuthN's complexity.

I'm personally not very opinionated on the implementation details. I think that as long as they allow:

• Control over AuthN response success/failure.
• Preventing changes (updating data, registering a user...)
• Control over token data.

Let's lay out the endpoints that should have hooks, with a use case for each.

You mentioned an implementation w/ HTTPS with Basic Auth. I'm not exactly sure of what the need for auth here would be, since events would only come from AuthN and not viceversa?

The app handling hooks needs to trust that they come from AuthN.

I was thinking about the specific timing for the events (after actions, before, or both)

I'd aim for before the action but after the validation.