Advertisement

Keep checking credentials on Rest API?

Started by July 03, 2016 04:39 PM
3 comments, last by user123456789 8 years, 4 months ago

Hi,

I created a Rest login to communicate between Java and MySql. I want to extend this to a game but I'm not sure how to make this secure for each action that changes or looks up sensitive/private data. I currently let the user login with a guest account and give him a option to register with email and a proper user name. I keep this data locally, so the next time the application is opened it logs in automatically.

But what about each action through the Rest API? Should I ask for username/ID and password each time and verify that? Since the password is BCRYPT'ED with a preferable high cost this takes a long time for each action through my API. So am I missing something here? Can I create some kind of session for the Java app so the client "stays connected" /" does not need to check user/password". Or am I missing something here and isn't this necessary at all?

I guess there are more than one way to do it.. but one solution which works pretty good is using a token-based authentication.

The way it works is that once you do your request with username/password to the server you will need to generate access-token which is returned as a response on successful login. After that, you will place this access-token to be part of your subsequent requests to the protected server-side routes which in turn needs to check the access-token validity each time. This check is typically done as a filter or "before_action" as they call it in the Ruby On Rails world.

Nevertheless, the type of token you generate and how you store it varies as well. I've seen implementations in which tokens are saved to database table and the tokens itself are just a random combination of numbers/letters etc. without any real knowledge in it. For this, you most likely need a database table such as "sessions" which has fields like "access_token, user_id, expires_at".. and after that, you can use "expires_at" field to dictate how long the token is valid. And implement things like "refreshing" token duration and even revoking access.. the user_id here is useful, as like with cookie-based authentication, you often need to know the session user at the server.

Here is more explanation about this approach: http://stackoverflow.com/questions/1592534/what-is-token-based-authentication

However, how I would actually do it (today) would be using json web-tokens because they doesn't require reading/writing to database at all. Instead, the secret used to generate the token is stored to server-side and the token itself carry the information of expires_at and a like. You can even place your user_id and other (less critical) information there. You can read more about it here: https://jwt.io/

And finally, you should treat tokens as passwords. Meaning, send them over https connection.

-

Advertisement
This is no different from logging in to a website. On a website, you get a session cookie, which typically is something like "userid:expirytime:unique-id:hmac(userid,expirytime,unique-id,key)."

You can issue a similar session token to the users of your REST API. In fact, because you already use HTTP, you can still use cookies. (For UDP based connections, you'll need to manage this cookie at your own protocol layer.)

It's important that you do verify the cookie hmac, and that you do verify the timeout/expiry time. You will also want to issue a new session token when the expiry time gets close, if you want the user to keep the session alive.

Another option is to use OAuth for your API calls. However, as maunovaha suggests, implementations of that typically require looking up the token in some database. You could make that database be memcached or Redis, to make it fast, but it's still slower than "verify the hash."
enum Bool { True, False, FileNotFound };

Thanks,

I really like the idea of a token so I think I will be generating my own tokens with userID + random string to make it unique and store this on the client and database. But this leaves me with a security question. I guess I have to use https and I have no experience with this. Can I just develop without SSL and when I deploy the app install SSL on the server? Obviously I need to change all my http web requests to https but I can just change my domain string to achieve this. Or should I setup a SSL connection with XAMPP to continue developing locally? I tried setting it up locally with my own certificate but I'm experiencing problems and I rather just continue developing :).

Sure, you can develop without https connection, but if you don't have any other environment (like staging) between your development <--> production, then you might encounter bugs as you suddenly switch using https and some of those web request/asset urls are not properly set to use https. So I would at least test that https setup locally, before just activating it for the production. Nevertheless, I still suggest that you should prefer using json web tokens over making your own system as it is less hassle and they have library for Java as well. But the choice is yours ofc.

-

This topic is closed to new replies.

Advertisement