1

I am implementing a webapp that make use of an internal/private rest api for backend processing. I plan to implement a token based authentication for it. Im reading on stuff about it, and bumped into X-Auth tokens, and Bearer Tokens.

I don't see much difference between them since they are both headers with generated tokens. But I would like to do it the standard way.

Which of those is more appropriate for my needs. If not, what type of token is more appropriate?

froi
  • 7,268
  • 5
  • 40
  • 78

2 Answers2

0

I'll just answer my own question just in case it would be useful to others.

We ended up implementing a process using an Authentication header with a Bearer token. It's basically a token you give out to potential users/clients.

One way you can give it out is via an authentication endpoint, if they pass in the correct user name or password you can respond with the Bearer token.

Succeeding requests to protected resources then would use that token in the Authentication header.

A bit of reference about it: https://www.rfc-editor.org/rfc/rfc6750

A good explanation here:

What are Bearer Tokens and token_type in OAuth 2?

Hope it helps.

Community
  • 1
  • 1
froi
  • 7,268
  • 5
  • 40
  • 78
  • Make sure you use correct grant_type, because in today's applications its almost impossible not to expose your api to your partners or developers. Keeping clean separation of grant_type(s) for internal applications (client_credential), internal authentication(password) and third-party (authorization_code) etc, helps you maintain AuthN/AuthZ for long term. – Abhishek Tyagi Oct 25 '16 at 18:27
-1

I think there is no universal answer to this. First of all, I suspect you might confuse headers with tokens, so let's start from here. This is a snippet from whireshark, usual HTTP GET method:

GET /22789/610/144208714.mp4?token2=1404763288_a4b48d3fc547294893b3b8d817ef1c59&aksessionid=690e90bada20cdc5 HTTP/1.1
Host: pdl.vimeocdn.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
DNT: 1
Range: bytes=427217-
Referer: http://vimeo.com/59253805
Cookie: aka_debug=cpcode:133150~clientip:87.81.132.48~ghostip:176.255.247.64~requestid:57d39e3~time:1404762182~ghostforwardip:~edgecache:cache-hit
Connection: keep-alive

Notice how token sits behind question mark in the body of GET request line. Whatever follows '?' is called request parameter, it is up to you whether you name this parameter 'token', 'token2', or 'mysuperhash'. In this particular example the token starts with unix-like timestamp, so if you go and try paste this exactly request to your browser, access will be denied as the link has expired.

Every line that follows the first one is basically a header. Although there are some conventional headers (e.g. Host or Time) it is entirely up to you how to name your header that you would like to use for your specific purposes.

In nginx and Apache servers you have variables that are always there via which you can access parameters and headers with equal ease. Furthermore, nginx allows you configure conditional access based on tokens so that you don't even need be a programmer (save for ability of getting config lines right), you could have a look: http://nginx.org/en/docs/http/ngx_http_secure_link_module.html

It is a certain architectural decision how to construct that token. You can protect the access based on time, on whole URI, client's IP address and so on. Normally, it is more complicated than it looks, as you will need to take into account many possibilities in access networks an authorized user might be behind. In case of nginx you are limited with md-5 hash. It is old-good-fast method, but it is deemed compromised, so if you want a better protection you might consider sha-1 in your own implementation (libraries are available in openssh package).

wick
  • 1,995
  • 2
  • 20
  • 31