API naming for authentication API composed by many steps

Question

I have an API which include a registration and login process. Both process have an authentication sub-process. This sub-process are many steps which API validate a client specific data.

I have many doubts about names for authentication process. This is my approach:

Registration process (It creates an account)

POST /accounts/authentication (start authentication process, generate internal keys but doesn't return any token)
POST /accounts/authentication/data1/validation (validate data1 of client)

Login process (When client want to access his created account)

POST /sessions/authentication (start authentication process, generate internal keys but doesn't return any token)
POST /sessions/authentication/data1/validation ( validate data1)
POST /sessions/authentication/data2/validation ( validate data2)

Additionally, I have a service which return the data (data1 or data2) that I should validate in a next step.

GET /attributes 

( I can't specific the real name but My approach it should be a plural noun)

Well, I would like if my approach is correct.

Thanks!

EDIT 1

Firstly, I have a token which is generated previously. I sent this token in headers. Then, the first service (.../authentication) generate internal tokens. The next services validate these tokens internally. Due to security reasons I can't use these tokens in URL's.I have a Redis DB which support all process.

Regarding to the another service (.../data1/validation). "Data1" is an specific data attribute of the client. According to business rules and application flow, I need an specific service for validating this specific data attribute.

I hope my additional explanation could help you to understand my problem.

Thanks :)

Answer 1

As a practice, you try to associate a url with a resource rather than behaviour. with that in mind
POST /accounts/authentication: I don't understand what start authentication process does, but if you are generating a token, let's just say GET /token. When you are using POST, generally your data does not go in the URL as mentioned in POST /accounts/authentication/data1/validation This should be a really good guide: resource-naming

Answer 2

From the question it is not exactly clear how server-side remains stateless. There is one pattern, which may be useful for representing a process.

The idea is to create a temporary resource (eg registration or login) in a relevant store, and then work by addressing them.

For example:

POST /accounts/authentication
# this will give you Location: /accounts/authentication/01234-6547
POST /accounts/authentication/01234-6547/data1/validate
...

You can even get the status, which will possibly return links to more steps, if needed (in a more HATEOAS fashion):

GET /accounts/authentication/01234-6547

I do not remember where I got that idea originally, but this article seems to describe the approach.

All that said, unless you are working on OAuth3 or something very new, it's probably better to stick with how it is usually done in some mature systems even if it is not quite REST. This relates to how secure the solution will be and small details may matter.