1

I am new and need directions so I can ask the correct questions. Here's the deal:

I have developed a REST API under HTTPS.

The user must provide a valid token to use the API.

The token expires after not being used for more than 5 minutes.

To obtain the token, the client must call the authentication API passing his private primary or secondary key, along with his user number.

Each key is unique, and on the database I save it's hash. The user passes his primary or secondary key through the header with key "pk" or "sk" and "usernumber".

The server will get those keys and send to the database, which will apply the hash and check if they are valid.

Once the keys are valid, a token itself is generated on the database, and returned to the user.

My concern regards passing the primary key or secondary key on the headers. I am not sure if someone can obtain those data from outside and neither if it is the best practice. I am trying to get some directions, and I have came upon basic auth, oauth, and others. But they all seem to be on HTTP. I have not found much about API HTTPS, so I also need some directions here. Can I make my API accept only https requests? If so, does the same security rules apply?

Thanks in advance.

Macaroni and not cheese
  • 149
  • 1
  • 1
  • 13

2 Answers2

1

First of all: regarding HTTPS VS HTTP.

HTTPS is HTTP over TLS, where TLS is another layer of protection meant to secure the communication channel. All HTTP rules regarding headers apply to HTTPS too. TLS will protect your data confidentiality and integrity. It will protect the whole HTTP request including headers and body.

Regarding passing secrets as headers.

It's ok to pass secrets as headers or body. It's not ok, to pass secrets in URL. It's not ok to log out secrets on servers and proxies along the way. It's not ok to implement your own authentication mechanisms unless really needed.

If you want to read more about what is required to protect the communication channel (and the rest of the application), look into the OWASP Application Security Verification Standard.

Marek Puchalski
  • 3,286
  • 2
  • 26
  • 35
1

There are 4 security aspects to consider. Most of the frameworks define the flow for Authentication and Authorization. Some frameworks define Integrity as well via Signatures.

But almost all heavily rely on encrypted data for for Confidentiality. i.e they recommend HTTPS if the communication is based on HTTP

  • Authentication:

    Identifying who is talking to your API.

  • Authorisation:

    Once you have identified who is talking to your API, ensuring they have the permission to talk to. If authentication is like checking someone's Id and allowing them into the building. Then authorisation is like allowing them to go into room for which they have access code.

  • Integrity: One you know who are you talking to and what they are allowed to do, you still need to make sure that data you are receiving is from them and not tampered data.

  • Confidentiality May be they are not tampering the data but reading all the data over the wire so later they can use that data and pretend to be the person you trust. So except for the sender and receiver no one else to see the data.

Note:

  • The above 4 aspects are for security on the flow.

  • You also have to consider security at rest. You seems to have strong design here on the server side for this aspect.

  • Have you considered what would you do when the token expires after 5 minutes. You user won't be happy entering user number and primary key/secondary key every 5 minutes. And if you plan to store it on client side so you can automate it every 5 minute, then you have to think about where would you store it in the client side and security at rest aspect for that

Kavithakaran Kanapathippillai
  • 7,883
  • 1
  • 11
  • 29