Digest, Basic, and Bearer Authentication

Question

I recently posted a problem I was having with authentication, but didn't receive any replies so I thought of another way to ask the question without being redundant.

What I'm seeing in the applications documentation are three ways to pass the access token to authenticate and receive the information that I'm trying to get: HTTP Digest auth, HTTP Basic auth, and Bearer token auth. The distinctions between these is unclear to me, and my attempts at Bearer token auth (check out STEP 5) have not worked.

Can someone explain what these three are and hopefully point out what I'm doing wrong?

Answer 1

"HTTP Basic Auth" and "HTTP Digest" authenticate using username and secret. The HTTP Digest auth is more secure as it don't send username and secret as plain text.

"HTTP Bearer Auth" authenticate using access_token.

Your HTTP Bearer Auth code looks ok to me.

Answer 2

There is not much difference between HTTP Basic Authentication and HTTP Digest Authentication.

For basic Auth Before request with the oAuth system user name is appended with a colon and concatenated with the password. The result will than be encoded with the Base64 algorithm.

For example say username is demo and your access_token is 123 so in this case the resulting string after concatenation will be 'demo:123' and once we apply Base64 encode, it will become ZGVtbzoxMjM=

Now this encoded string is transmitted in the HTTP header and decoded by the oAuth provider.Again this is not a very strong encoding mechanism and can easily be decoded as this Auth system is not meant for very high secure system.

Again Digest also use HTTP protocol to send and recieve data but its much better than basic OAuth which send data in plaintext.Digest uses MD5 cryptographic hashing type of algorithm to encrypt your password/access_token and beside this it use nonce value to stop replay attack.

Hope this will give you some idea about the way they work.

Update

i just saw the code at Gimme bar

GET /api/v0/tags HTTP/1.1
Host: gimmebar.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/533.6+ (KHTML, like Gecko) Version/4.0 Safari/528.16 Titanium/1.1.0
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Authorization: Digest username="funkatron", realm="GimmeBarAPI", nonce="7a3ab1f9cde605f27797cd04c4d1fcf6", uri="/api/v0/tags", response="3654f9b1b2ba9489e1f01ae792852987", opaque="94619f8a70068b2591c2eed622525b0e", algorithm="MD5", cnonce="6897ccbff3b08776ab61e69a814c05b4", nc=00000001, qop="auth"
Connection: keep-alive

and if you see while sending the request they are passing the hashing algorithm used along with nonce,username.So all they are creating them in there application and placing in the header section.All you need to find what header name we need to put.

Answer 3

The bearer token is generated server side when you authenticate against the server. Then for any subsequent request you supply the generated bearer token in the request header.

From a security perspective these tokens get generated using a private key, only the server authenticating the user knows this key

Look at jwt they have really good documentation on this specific topic

The gimmebar documentation is pretty clear on how to gain access

POST /api/v0/auth/reqtoken HTTP/1.1

Response Message

{"request_token":"390a9b193fc51be1a78d13bf69555212","expires":1309375411}