views:

400

answers:

5

Hi guys. I am designing a web api. I need to let the user authenticate themselves. I am a little hesistant to let the user pass in their username/password in cleartext.. something like: api.mysite.com/auth.php?user=x&pass=y

Another option i read about was Base64 encoding the username/password and then sending a HTTP request. So does that mean that on the server side;I would _GET['user'] and _GET['password'] and then somehow decode them?

Is that what twitter does: http://apiwiki.twitter.com/REST+API+Documentation#Authentication ?

+3  A: 

Base64 is no protection at all. Use SSL for real security.

truppo
then how does twitter api use security? http://apiwiki.twitter.com/REST+API+Documentation#Authentication
shergill
They are using HTTP Basic Auth, which is plain text, which the poster did not want.
truppo
i'm just wondering.. if it is not a problem/issue for twitter; then is it really such a big deal?
shergill
+2  A: 

If this is a webservice, you'd better use more secure form of authentication. Look for example, at the LiveJournal protocol: Challenge-Response.

Eugene Morozov
how does twitter api manage this: http://apiwiki.twitter.com/REST+API+Documentation#Authentication?
shergill
+3  A: 

Just this week the IETF published a new draft discussing security properties of the various authentication mechanisms in HTTP. You should find helpful information there.

Personally I'd recommend at least to read about digest authentication and analyze if that's suitable for you.

Using SSL might also be an option. However, it also addresses additional issues at the expense of performance, cachability and others. It keeps the payload data confidential. If this is a requirement, then it's your way to go.

mkoeller
+3  A: 

As mentioned by truppo, first use SSL.

What many web services do is have an "authenticate" service that returns a token that is then used later, and can be used in plaintext, since it's only valid for a limited amount of time. When it expires, the client simply does another authenticate.

The key benefit of this is that it reduces the number of SSL requests, which lightens the load on the server.

Tim Sullivan
+1  A: 

Please do not use regular usename/password authentication for the api. People really shouldn't be forced to put credentials from foreign services in a mashup service.

Please consider using oauth http://oauth.net/ or at least some challenge-response based system, like Eugene suggested.

One easy way would be to let the guest-service generate a token which is connected to his app and a user. If you put in some work you could even make the tokencreation secure to have only allowed foreign services with some private/public-key mechanisms.

The user has to authorize this token in your app before the guest service can use it to get authenticated.

squiddle
Thanks for your feedback. I am going to implement the challenge-response system.
shergill