Ask HN: How are you authenticating rest service clients

14 pointsdevb0x12y ago12 comments

I've been playing with asp.net webapi and basic auth header (with user:pass in base 64).

If you have a angular or knockout front end, are you storing the login details in a cookie and passing in the header, or via a token? Where are you storing that token?

I am new to this sort of api / javascript front end and want to deal with security according to best practice.

What do you recommend?

Ask HN: How are you authenticating rest service clients

14 pointsdevb0x12y ago12 comments

I've been playing with asp.net webapi and basic auth header (with user:pass in base 64).

If you have a angular or knockout front end, are you storing the login details in a cookie and passing in the header, or via a token? Where are you storing that token?

I am new to this sort of api / javascript front end and want to deal with security according to best practice.

What do you recommend?

12 comments

9 comments · 3 top-level

tptacek12y ago· 4 in thread

Don't use usernames and passwords as API authentication. Generate a random 128 bit token for each user (RNGCryptoServiceProvider, GetBytes on a 16-byte array) and pass that as a header (or as Authorization). Make sure your API endpoints require HTTPS.

BillinghamJ12y ago

Couple of additions:

1 - plain username/password

If you have an API call for logging the user in with a username & password which only your app should use, and you're (very) paranoid about someone else using that call, consider using a client SSL certificate.

Securing the request via a client SSL certificate will prevent the replication of that request by another app unless they go to the lengths required to actually disassemble your app.

2 - token generation

In the OAuth implementation for the system I'm currently working on, we decided to simply encrypt the ID of the row (plus a salt) for that access token, rather than generating a random string.

This has two benefits:

- it is extremely fast to look up the access token in the database, since we're using the primary key, rather than searching for a string

- no possibility of collisions

If this is a flawed approach, please let me know. We're using AES & are encrypting "AccessToken" + ID, so replay attacks from other encrypted data aren't possible.

bmelton12y ago

I assume this is predicated on an initial username/password auth for identification? If not, how do you deal with token assignment?

E.g., if I log in today, then come back on a different computer, how do you know to give me the same token?

I've always copped out on REST auth and just gone client/server for authentication, with REST for everything else, for fear of fucking it up.

BillinghamJ12y ago

The token is held by the client using the API.

1 more reply

devb0xOP12y ago

following on bmeltons question, the user must still log in, so the username / password is only entered once and this token is then returned? What about session expiration, how is that determined, and what about a user logging on from different devices - a token for each device ?

jo_12y ago· 1 in thread

Speaking purely from the backend, our login function takes the IP address of the requester, the login name, and password, then checks the password against the database. If the password matches up, the current date and time, the current IP, the current time, the session expiration date, and a buttload of details about the host machine are hashed together and encrypted with the system's public key before being sent back as a token.

It's up to the client to store the token however it likes, but our reference implementation stores it as a cookie on the local machine.

If a new request comes from an IP address which doesn't match the encrypted token, or if there are system details in the encrypted token which don't match up with the one on file (we restrict sessions to single instances), then the request is rejected.

devb0xOP12y ago

thanks, so basically you're hashing a token a each time a request comes in you decode.. do you increase the session expiration date or keep it as is?

junto12y ago· 1 in thread

We use ServiceStack with .NET and love it.

ServiceStack uses a HTTP cookie and supports a variety of authentication options out of the box, including basic auth.

https://github.com/ServiceStack/ServiceStack/wiki/Authentica...

We also use the easy hooks that ServiceStack offers to validate API developer / app tokens as well.

Social Bootstrap API is a backbone example:

https://github.com/ServiceStack/SocialBootstrapApi

https://github.com/ServiceStack/ServiceStack.Examples

http://stackoverflow.com/questions/15862634/in-what-order-ar...

It also has various other goodies, such as:

https://github.com/ServiceStack/ServiceStack/wiki/Metadata-p...

https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-co...

https://github.com/ServiceStack/ServiceStack/wiki/Plugins

https://github.com/ServiceStack/ServiceStack/wiki/Clients-ov...

It also doesn't require ASP.NET and can run on Unix under Mono.

Try it, you won't go back to WebAPI is guarantee it!

devb0xOP12y ago

gees thank you for all that Junto!

j / k navigate · click thread line to collapse

12 comments

9 comments · 3 top-level

tptacek12y ago· 4 in thread

BillinghamJ12y ago

Couple of additions:

1 - plain username/password

Securing the request via a client SSL certificate will prevent the replication of that request by another app unless they go to the lengths required to actually disassemble your app.

2 - token generation

In the OAuth implementation for the system I'm currently working on, we decided to simply encrypt the ID of the row (plus a salt) for that access token, rather than generating a random string.

This has two benefits:

- it is extremely fast to look up the access token in the database, since we're using the primary key, rather than searching for a string

- no possibility of collisions

If this is a flawed approach, please let me know. We're using AES & are encrypting "AccessToken" + ID, so replay attacks from other encrypted data aren't possible.

bmelton12y ago

I assume this is predicated on an initial username/password auth for identification? If not, how do you deal with token assignment?

E.g., if I log in today, then come back on a different computer, how do you know to give me the same token?

I've always copped out on REST auth and just gone client/server for authentication, with REST for everything else, for fear of fucking it up.

BillinghamJ12y ago

The token is held by the client using the API.

1 more reply

devb0xOP12y ago

jo_12y ago· 1 in thread

It's up to the client to store the token however it likes, but our reference implementation stores it as a cookie on the local machine.

devb0xOP12y ago

thanks, so basically you're hashing a token a each time a request comes in you decode.. do you increase the session expiration date or keep it as is?

junto12y ago· 1 in thread

We use ServiceStack with .NET and love it.

ServiceStack uses a HTTP cookie and supports a variety of authentication options out of the box, including basic auth.

https://github.com/ServiceStack/ServiceStack/wiki/Authentica...

We also use the easy hooks that ServiceStack offers to validate API developer / app tokens as well.

Social Bootstrap API is a backbone example:

https://github.com/ServiceStack/SocialBootstrapApi

https://github.com/ServiceStack/ServiceStack.Examples

http://stackoverflow.com/questions/15862634/in-what-order-ar...

It also has various other goodies, such as:

https://github.com/ServiceStack/ServiceStack/wiki/Metadata-p...

https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-co...

https://github.com/ServiceStack/ServiceStack/wiki/Plugins

https://github.com/ServiceStack/ServiceStack/wiki/Clients-ov...

It also doesn't require ASP.NET and can run on Unix under Mono.

Try it, you won't go back to WebAPI is guarantee it!

devb0xOP12y ago

gees thank you for all that Junto!

j / k navigate · click thread line to collapse