Extended Basic Authentication

Question

I would like to implement a REST API with Basic Authentication which relies on username and password. Because REST is stateless the user would have to reenter username and password for every request without storing them in a cookie. As storing username and password in a cookie is not an option another solution is needed.

The scenario I’m thinking of will be as follows:

1. User navigates to https://www.myapi.com/login
2. User enters username and password (encrypted with SSL).
3. System checks if provided credentials are correct.
4. If correct: System generates a GUID, encrypts the GUID with password of user and sends it to the user.
5. If not correct: Increase FailedPasswordAttemptCounter and check if login should be locked for the user.

As the response of the server to the client is not encrypted the GUID is encrypted with the password of the user. Only the user is able to decrypt the GUID.

The user provides the GUID for all other resources which needs authentication instead of username and password.

Is this approach better compared to providing username & password for each request?

I’m aware of the fact that someone is able to generate GUIDs and tries to authenticate with them. But a targeted attack on a specific user is nearly impossible as the login resource provides a lock mechanism.

My question is somehow related to this one: https://stackoverflow.com/questions/290405/is-using-a-guid-security-though-obscurity

Answer 1

Because REST is stateless the user would have to reenter username and password for every request

Is directly contradictory to

The user provides the GUID for all other resources which needs authentication instead of username and password.

You can either:

A. send the password with every request, or
B. don't send the password with every request.

But you will have to pick one.

Here's the ideal scenario. It's close to what you're describing:

1. The user logs in. Username, password, authentication token, whatever.
2. The server stores that authentication event server-side and creates a random token (GUID or whatever you want) to give to the client
3. When the client want to send his request, he also sends the token which identifies him to the server. It could be in a cookie, in the URL, in a form variable, in a separate header. Doesn't matter. Anywhere in the request is fine.
4. The server expires the token after it's no longer supposed to be used. Perhaps it's good for 5 minutes, perhaps it's good until it's been used for one operation. Perhaps it's good until it goes unused for 5 minutes. Whatever you want.