35

Overview

I am developing a mobile application using PhoneGap with REST API for the backend. The REST API won't be utilised by third-party developers, but will be application-specific, so there is no need for oAuth to be implemented. Hence, I am planning to use Basic Authentication where in the User enters their Username/password to access the API resources. All API communication will be on SSL.

Basic Authentication with Token

Instead of letting the application store the username/password and send it with every request to the API, I would rather authenticate username/password on the first login request and send a GUID token back. The client stores this GUID token and sends the token back to the API with each request through the Authorization header, like this:

Authorization: Basic e1d9753f-a508-46cc-a428-1787595d63e4

On the server side, the username/GUID combination will be stored on the server with a expiration date along with device settings. This will allow to keep track of the number of devices a user has logged in from as well as expire the session once the Guid has reached expiration.

Does this approach sound reasonable and secure?

badikumar
  • 807
  • 2
  • 8
  • 18

2 Answers2

31

There is no need for you to create custom headers or authentication schemes at all.

The Bearer authentication scheme is designed exactly for your use case:

Authorization: Bearer e1d9753f-a508-46cc-a428-1787595d63e4

Basic authentication must be as follows:

Authorization: Basic base64EncodedUsernameAndPassword

where base64EncodedUsernameAndPassword is equal to the output of:

base_64_encode(username + ':' + raw_password)

Do not use Basic if the trailing text value is not the above exact algorithm.

If you just want to put whatever value you want after the scheme name, use the Bearer scheme - that is what it was invented for.

Warning

While you can use a simple GUID/UUID as your token, this isn't really a secure token. Consider using a JWT instead. JWTs can be digitally signed and assigned a TTL so that only the server setting it can a) create it and validate its authenticity and b) ensure it is not used longer than is allowed. While this may be true of your data stored based on the GUID, the JWT approach does not require server state - so it scales far better - and accomplishes the same thing.

Community
  • 1
  • 1
Les Hazlewood
  • 18,480
  • 13
  • 68
  • 76
  • 4
    i think for specific scenario at the end both jwt and guid are only a token , for example suppose we are not storing any sensitive info in token whether it is jwt or guid token , so then what extra benefit a jwt will provide instead of a guid token. – Dragon Mar 23 '17 at 18:37
  • A JWT does not "accomplish the same thing" as a token which references a server table. You lose the ability to modify the state of the token because a JWT is stateless and only expires when its time is up. – James Hurley Nov 04 '22 at 17:54
  • @JamesHurley not so - you do not lose that ability. Stateless applications read the token data on the inbound request as needed, and if state/data modification is necessary, they issue a *new* token (either with an extended expiration or retaining the existing one) on the outbound response reflecting the new state for all future requests. The case stands that because server state isn't required (even on data changes like this), it scales far better. Most large-scale web applications (Facebook, Google Apps, etc) use this technique to avoid server state when possible. – Les Hazlewood Nov 06 '22 at 19:10
  • I see where you're coming from, but I don't see how that applies to the general case. My specific example would be endpoints which place a product order, but with a single-use authorization token (sent in an email.) you click the link, become authorized, and a stateless token is sent with an expiration of whatever is feasible (because the single use can't be used as a persistent token). You complete your order. How is the most recent token invalidated? With a stateless token the invalidation would need to occur in every endpoint, because the stateless token is valid until expired. – James Hurley Nov 07 '22 at 21:41
17

The general "Authentication with Token" approach is very good but you shouldn't try to make Basic Authentication work in different way than it is supposed to (after all it is a defined standard). You should rather use your own header for authentication purposes. You can find a very good description of such scenario here:

tpeczek
  • 23,867
  • 3
  • 74
  • 77
  • In other words, I can use Basic Authentication for the first login request and thereafter have the client send a custom header "X-Auth-Token: e1d9753f-a508-46cc-a428-1787595d63e4" with every request? – badikumar Aug 23 '12 at 08:17
  • 7
    And do not use X in custom headers names, that's deprecated. http://tools.ietf.org/html/draft-ietf-appsawg-xdash-05 – Filip W Aug 23 '12 at 11:48
  • @tpeczek what if we send guid token as a json object rather than in some header, and when recieving take in action parameter rather than header.Is it a good practice any issue with this approach.I am asking this since in the api is also used by android and ios clients along with angular web. – Dragon Mar 23 '17 at 18:33
  • 1
    @Dragon If I have understood you correctly, my question would be what about requests which can't have content (for example GET). You wouldn't be able to pass token as part of payload for those. – tpeczek Mar 23 '17 at 20:31
  • @tpeczek no no i meant that if we pass token in parameter , i.e Get api/Product?token=abc. and in case of Post api/Product and token in object. In both these cases we are not passing token in header. and sorry for bad explanation. – Dragon Mar 23 '17 at 21:05
  • @Dragon So this should have some additional security consideration. If the URL gets somehow exposed in the UI it is just enough to retype it to gain access. But if done with special considerations in mind when you are forced to go down this path, this could be considered a solution (certainly not a "kosher" one). – tpeczek Mar 24 '17 at 10:04
  • @tpeczek i think if it is not safe in parameter then it is also not safe in header as header is also exposed at client side and anyone can get that token using postman or developer tools and can gain access using that token i.e can make requests and we don't have any mechanism to identify the fake and orinal user. – Dragon Mar 24 '17 at 10:31
  • @Dragon The general level of security is the same (in general both ways require HTTPS to be considered safe). The only difference is the URL is easier to accidentally expose. As long as you keep that in mind you should be safe. – tpeczek Mar 24 '17 at 11:10