Registration flow

[zacharygoulet]

Hey, I've been looking at Rauthy and trying to use it for a side project and I've got a couple of questions regarding the registration flow.

1. The docs explain that you can host your own UI (which is what I want to do in my case) for registration. Does that also include the confirm email / set password-passkey section? I didn't see any way to change the link provided in the email which would allow that if I'm not mistaken? And it would make sense to also have my own UI for that step.
2. Rauthy uses a flow where the registration endpoint only takes the email, and than the user sets its password when validating the email. This is different than what I'm used to, where the password is given at the same time as the username, and the verification email is just a link to confirm the email. I'm just curious if this is an opinionated design decision for rauthy? Is there an advantage to do it this way or is it just 2 valid way to do things and Rauthy just happened to choose that one.
3. When a registration is done, Rauthy adds the user and wait for the confirmation step. Meanwhile, trying to register again becomes an error (400). Should it not be successful and send the confirmation email again? If the email confirmation link becomes outdated, does it remove the user from the database and make the registration endpoint valid again?

Thank you!

NB: I'm newish to authentication so sorry in advance if any of my question are obvious!

[sebadob]

The docs explain that you can host your own UI (which is what I want to do in my case) for registration. Does that also include the confirm email / set password-passkey section?

Kind of, yes, but it's not too straight forward. The reason is that all Passkey related actions must be done on the exact same origin. So you have 2 ways of providing your own UI for UIs where you can not just do the requests from another origin:

1. Route overwrite via reverse proxy: You can host your own UI parts alongside Rauthy, and then overwrite the specific routes (e.g. for password resets or the account dashboard) with a reverse proxy, which sits in front of your appplications.
2. Custom compile from source: You can of course also check our the latest tag, modify the UI to your liking and compile from source. This is a lot more powerful, but also needs more maintenance during updates. Rauthy is pretty stable by now and the v0.32 is kind of the one I want to just keep running for a while and see if there are some bugs or last issues, before releasing v1.0.0, but it can of course happen at any time, that some UI parts are being updated with a new release. So if you want to do this, you need to diff the files you overwrote and possibly adjust them to get your custom UI back including the latest updates.

If you only want to do the registration, you don't need any of that, because you can do the POST request from an external source:
https://sebadob.github.io/rauthy/config/user_reg.html#custom-frontend
https://iam.sebadob.dev/auth/v1/docs/#/users/post_users_register

Rauthy uses a flow where the registration endpoint only takes the email, and than the user sets its password when validating the email. This is different than what I'm used to (...).

There are multiple reasons why it is like that and yes there are some clear advantages:

1. Password hashing is extremly costly and you want to avoid it, if it's unnecessary. When users register, but just for testing or they don't provide a valid email, or for whatever reason, you don't want to do the hashing before they confirmed, that they really want to register.
2. E-Mail providers like especially Microsoft are getting worse every day. If you have your mails in the azure cloud, microsoft pretends to be "helping" and "securing" you by scanning all your emails and using all links, and scanning the targets. This means you could even "confirm" a users email without any user interaction, because Microsoft basically clicks each link they can find without you knowing or your consent.

When a registration is done, Rauthy adds the user and wait for the confirmation step. Meanwhile, trying to register again becomes an error (400).

Yes and it makes total sense like that. Your user is already registered, so why should it be possible to do this again? This makes no sense. Unconfirmed users will be auto-deleted after the link expires and was never used, if you have an open registration endpoint. This makes sure that even if a bot or spammer would do the full registration incl the PoW, they would be cleaned up automatically if they don't complete the flow.

[zacharygoulet]

Thank you for the fast and thorough answer!

Kind of, yes, but it's not too straight forward. The reason is that all Passkey related actions must be done (...)

For that part, I think I will want the reverse proxy option then. I'm not so sure to have understand the problem and how the reverse proxy solve it fully yet, but I'll investigate it, thanks for the pointer.

There are multiple reasons why it is like that and yes there are some clear advantages (...)

Thanks, that makes sense, that Microsoft thing is crazy I did not know that...!

Yes and it makes total sense like that. Your user is already registered, so why should it be possible to do this again? (...)

Ok, makes sense overall, but if a bot (or another user) uses the email of someone else (on purpose or by accident), and that user then tries to register, they would get an error. Wouldn't that be confusing for the user? It would look like the app is not working properly, or that the email was stolen and successfully used. I guess they would have received a registration email in the previous days, so they might have noticed it, but maybe not too. Also, if they inadvertently delete the confirmation email, than they have to wait for an unknown (for them) amount of time to try again? (I do admit that both situation are unlikely though)

I also have a final question concerning registrations, is there a technical reason why Given Name is required. This is not really a blocker, but I probably would not have made it required for my app so I'm just curious.

Thanks again for your time!

[sebadob]

Ok, makes sense overall, but if a bot (or another user) uses the email of someone else (on purpose or by accident), and that user then tries to register, they would get an error.

Yeah and there is no issue with that, because if so, they would have received an email with the link to finish the registration, which some bot or spammer would not be able to use. They also would have not advtantage by doing something like this.

It would look like the app is not working properly, or that the email was stolen and successfully used.

Well, their email kind of got stolen at that point, even though not fully. And when they take a look at their account, only they have access to the finish registration link, no one else.

Also, if they inadvertently delete the confirmation email, than they have to wait for an unknown (for them) amount of time to try again?

That's correct. Or contact the admin to fix it. They could also go to the login page and request another password reset link from the form.

I also have a final question concerning registrations, is there a technical reason why Given Name is required. This is not really a blocker, but I probably would not have made it required for my app so I'm just curious.

No technical reason, but a logical one. Rauthy was developed for business use in the first place. In the beginning, even the family name was required, which I relaxed a bit. An account without a name does not make much sense in such a scenario.

[sebadob]

As an update for the given_name, it is not required anymore. All user values are configurable by now.