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?

Improve this question
3
  • The actual use of refresh tokens is still a topic for debate. see stackoverflow.com/questions/3487991/…
    – Cristian Dobre
    Aug 2, 2015 at 17:39
  • You should look into using OpenD Connect which is an Authentication protocol on top of OAuth 2.0.
    – jwilleke
    Aug 2, 2015 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, 2015 at 18:23

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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, 2015 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, 2015 at 19:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .