2

I'm quite a newbie at security.

I'm developing an android app with a token based approach to authentication. I'm not using Oauth as the OAuth 2.0 is not an authentication protocol but rather used to delegate authorisation: http://oauth.net/articles/authentication/.

Since I don't really want anyone else to use my API, I do not need to delegate authorisation so I have decided not to implement Oauth.

This is the flow:

  1. The user passes a username and password to the server using SSL
  2. The server verifies the username and password and passes back an authentication token using SSL. The authentication token is a random set of characters
  3. The authentication token is saved on the app and then sent back to the server each time a REST request is made using SSL

My question: are refresh tokens relevant in this scenario?

The authentication token is already encrypted through SSL and replay attacks or man-in-the-middle are not possible.

Also the authentication token is used only for access my API and not used subsequently in any further API calls from server to server (like for example, if I call the google maps server from my server, I don't use my authentication token to make the call - the token is unique for my server).

I could make the flow more secure by hashing the authentication token and sending that over to the server so that the server can check whether the hash of the token stored matches the hash sent by the app...

Why to use refresh tokens when your authentication token is securely transmitted through SSL?

  • The actual use of refresh tokens is still a topic for debate. see stackoverflow.com/questions/3487991/… – Cristian Dobre Aug 2 '15 at 17:39
  • You should look into using OpenD Connect which is an Authentication protocol on top of OAuth 2.0. – jwilleke Aug 2 '15 at 17:46
  • Hello - I did look at OpenID but since I'm not using Oauth 2.0, from my understanding, I cannot use OpenID? – Simon Aug 2 '15 at 18:23
1

Sounds like a good plan. Some things to watch out for are

  • Be sure to store password securely on server. There are lots of references on that. Good strategies will likely involve salt and bcrypt or PBKDF2.
  • Always use SSL. Best to restrict non-SSL via Web server if you can.
  • Use a secure random generator to get token.

That said, using your app server's authentication is likely the safest. Existing security systems are generally considered more robust than new ones.

  • Thanks Neil. I'm also wondering about the hash password and glad you brought it up. Would you hash on the server side? I would have thought one needs to store the actual unhashed tokens on the server side as the server would generally be more secure. A copy of the hash token would then be stored on the client side which it sends to the server. Once it arrives, the server will hash its token to do a comparison. – Simon Aug 2 '15 at 19:14
  • I'm not sure if you're confusing storing of the password with storing of the token. For password storage, see this answer them pay a be question if needed. For token storage, clear-text should be fine. Set a TTL on it that will require reauthentication to protect against it getting stolen. – Neil Smithline Aug 2 '15 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.