Is this login logic via RESTful call sound?

Question

(I am not talking about authenticating calls to RESTful API. I am talking about creating login logic for user via RESTful API.)

When user access any page of my site,

Answer 1

Session state on the client (not on the server)

That's what Roy Thomas Fielding, The REST Godfather, said in his dissertation regarding the stateless constraint:

5.1.3 Stateless

[...] each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]

So, if you are keeping the session state on the server, it's not REST.

In REST you won't have a session on the server and, consequently, you won't have a session identifier.

Each request must contain all data to be processed

Each request from client to server must contain all of the necessary information to be understood by the server. With it, you are not depending on any session context stored on the server.

When accessing protected resources that require authentication, for example, each request must contain all necessary data to be properly authenticated/authorized. It means the authentication will be performed for each request.

And authentication data should belong to the standard HTTP Authorization header. From the RFC 7235:

4.2. Authorization

The Authorization header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. [...]

Basic authentication

The Basic Authentication Scheme, defined in the RFC 7617, is a good start for securing a REST API:

2. The 'Basic' Authentication Scheme

The Basic authentication scheme is based on the model that the client needs to authenticate itself with a user-id and a password for each protection space ("realm"). [...] The server will service the request only if it can validate the user-id and password for the protection space applying to the requested resource.

[...]

To receive authorization, the client

1. obtains the user-id and password from the user,

2. constructs the user-pass by concatenating the user-id, a single colon (":") character, and the password,

3. encodes the user-pass into an octet sequence,

4. and obtains the basic-credentials by encoding this octet sequence using Base64 into a sequence of US-ASCII characters.

[...]

If the user agent wishes to send the user-id "Aladdin" and password "open sesame", it would use the following header field:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

[...]

Remember the HTTPS is your best friend to prevent the man-in-the-middle attack.

Tokens

If you don't want sending the username and the password over the wire for every request, you can consider creating a token based authentication. In this approach, you exchange your hard credentials (username and password) for a token which is sent in each request.

Again, the authentication must be performed for every request.

Basically, the token can be opaque (which reveals no details other than the value itself, like a random string) or can be self-contained (like JSON Web Token).

• Random String: A token can be issued by generating a random string and persisting it to a database with an expiration date and with a user identifier associated to it.

• JSON Web Token (JWT): Defined by the RFC 7519, it's a standard method for representing claims securely between two parties. JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords) in a payload, which is a JSON encoded as Base64. The payload can be read by the client and the integrity of the token can be easily checked by verifying its signature on the server. You won't need to persist JWT tokens if you don't need to track them. Althought, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To find some great resources to work with JWT, have a look at http://jwt.io.

There are many databases where you can persist your tokens. Depending on your requirements, you can explore different solutions such as relational databases, key-value stores or document stores.