12

I'm building a RESTful API for my application and I would like to make it as clean and transparent as possible.

I need to create an authentication endpoint and it makes most sense to me to build it so that users can authenticate in a following way:

GET https://example.com/
    auth?identity=<username_or_email>&password=<password>

As I said, passing the user auth data using HTTP GET method in query parameters just seems very clean to me.

But I would like you to ask about how secure it actually is. Considering it will be encrypted through SSL/TLS, do you think it's a good idea to transfer user credentials like this?

Hexdigit _
  • 187
  • 1
  • 2
  • 10

3 Answers3

13

As Display Name said, both variants are basically plain text (even using base64 encoding). So you must use TLS or another protection like HMAC

But from other side, Query string is less secure in terms of how Server/Client works with URLs in general. You can read about this here or here. Briefly you should be worry about the following

  • URLs are stored in web server logs
  • URLs are stored in the browser history
  • URLs are passed in Referrer headers
Community
  • 1
  • 1
Set
  • 47,577
  • 22
  • 132
  • 150
  • He is building a REST API; not something that will be visited from an end-user's web browser but instead gets called from another server. So there is no browser history and there is no referrer. Furthermore someone building an API should also be able to tweak the server's log settings so that sensitive data doesn't get logged (e.g. https://stackoverflow.com/questions/9467405/is-it-possible-to-exclude-specified-get-parameters-in-apache-access-logs/9473943#9473943). You should think about these kind of things beyond usernames and passwords anyway, especially with today's data privacy laws. – Arthur Jan 10 '18 at 12:01
  • 3
    @Arthur The point is that it leaves open the possibility that it can be opened in a browser with the aforementioned security risks, why leave the door ajar. – user2219808 Jun 04 '18 at 12:44
  • @user2219808 It is not leaving a door because there is no risk on the API side. You cannot protect users against actions that are not part of your application and that only harm themselves. That domain is infinite. – Arthur Jun 05 '18 at 00:14
  • 2
    @Arthur Nothing in the API says "do not call from a browser", who knows how it will be used in the future, that is leaving the door open. API's should not come with caveats. – user2219808 Jun 05 '18 at 11:45
2

Well I basically pass base64 string to the server. My username and password are converted in base64 and then passed in Authorization Header 

Authorization : "Basic --Value"

I find this the cleanest way of passing username and password to the server.

On the other end , server had a module called passport.Passport provides different type of Authorization and Authentication like Basic,bearer,token or even your own custom.

For the above purpose i use Basic Module.

maddygoround
  • 2,145
  • 2
  • 20
  • 32
  • 1
    The question is "how secure it actually is". The `Authorization` header is basically plain text. It can only be secure if TLS is used. –  Apr 25 '16 at 07:20
-1

From a security point of view it does not matter if you pass credentials as query parameters or in the Authentication headers. Both are basically plain text. So you must use TLS.

From a REST point of view, your URL looks like RPC: You call a method auth that accepts two parameters identity and password. What is the REST resource this URL represents? What happens if you make a second GET request with identical parameters? What is the response?

  • Thanks for your response. Talking about the REST point of view, requests of this type should return authenticatio data such as: `{"authToken": "x7kkoal1vf4uk34ikzep"}`. Making the requestst repeatedly should probably invalidate all of the previous `authToken`s and respond with similar JSON-formated data. – Hexdigit _ Apr 24 '16 at 07:16