How secure is keeping a token in angular for future requests to a Laravel API?

Question

I have an Angular JS Front end which consumes Web Services from an API developed using Laravel 5.

BACKGROUND INFORMATION 1

When the user logs in, if it's successful the API returns a token and the token it's like this:

$token = base64_encode("mail=" . $mail); 
return Response::json(["token" => $token, 'error' => null]); 

Then I have a function in an angular service that knows how to work with the token.

BACKGROUND INFORMATION 2

Every time a user needs to get data, the API takes the mail that is sent to the request as one of the headers request. In Laravel, I have a Middleware that takes that token and do the following validations:

1. The token is within the headers (in the authorization header)
2. The token is valid token
3. The email retrieved by the token exists on the database

If any of this validations fails, the API sends a 422 bad request with some error.

QUESTION

My real concern about this is, is it possible to someone to hack my website? Is it possible for someone (knowing someone else's email on the website) to change that authorization header that contains the email?

NOTE

In theory, the user gets a token if he/she had a successful login, if they didn't they won't get it.

Answer 1

The difference with your token (base64 encoded email address) and a JWT is that for a JWT it is much harder to create a token for another user. With your token, I can easily encode any other email address and obtain a valid token. A JWT, however, is cryptographically signed so that you can only create one if you have a secret key, that remains on the server.

If you want secure solution, it may be best to use some library that implements secure tokens like JWTs.

Answer 2

Considering that you appear to only Base 64 encode the email, it's easily bypassed.

Don't try to reinvent the wheel, especially for security.

Use a well known authentication library. After a user is authenticated, then retrieve data about them from storage based on their authenticated identity and pass that on as required.

Edit If you want to persist with this approach, then you should include a validation token with your json along these lines:

• At the point of log in, hash a (server-side) secret concatenated with the user email to produce a validation token.
• Send the token to the client
• When a request with a token arrives, you can verify that the email hasn't been tampered with by repeating the first step above and rejecting the request if the validation token doesn't match.

This prevents tampering with the email, though it doesn't stop someone from stealing the token and using it in a replay attack etc. etc.