Search code examples
restauthenticationuser-registration

RESTful registration with activation email

I'm working on creating a REST API and one feature is to allow users to register. The general flow is the following:

  1. The user specifies his email and password using the client application (SPA application) and presses the submit button.
  2. A request to the API is made. The API adds the user to the database, generates a verification token and sends an email to the user.
  3. The user verifies his email and clicks a confirmation link.
  4. The API marks the user account as verified.

My question is regarding the confirmation link. Should the link point to the client SPA application? In this case, the client application will make a POST request to the API with the verification token and the user email. Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?

Another approach would be for the link to go to an endpoint defined by the API. In this case a GET request will be made with the user email and verification token and the API will set the account as verified and inform the user that his account is now active. I have read that this approach doesn't conform to the REST principles because a GET request should never change the state of a resource. In this case, the user resource will be modified.

I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?

Thanks!

Solution

  • Should the link point to the client SPA application?

    If your 'Client SPA application' is the sole frontend for end-users, then yes: it should point there. Some people deploy a separate oauth2 / authentication server but that doesn't sound like it's the case here.

    The client application will make a POST request to the API with the verification token and the user email.

    The token should be enough. I'd avoid sending email addresses through urls.

    Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?

    Both seem like really valid designs. If you want the API to be completely unaware of the front-end and support a multitude of frontends, it would make sense to me that the client sends their own endpoints. There is a security concern though, you don't want arbitrary clients to register arbitrary urls.

    If you're just building a single frontend, I don't see a problem with the API knowing the activation url. It also sounds like it would be easy to change if your requirements change later.

    I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?

    Ultimately it doesn't really matter that much. Neither approach sounds like you're really painting yourself into a corner. Either you have a standard endpoint that uses a javascript HTTP request to activate a user, or you have a separate endpoint that redirects a user after activation. Both will work.