​RESTful Web Service Authentication Changes

Mike BerrymanI was trying to alter the authentication schema being used by one of our mobile apps.  This app communicates via REST web service calls to the server over a secure connection, so we were initially passing username/password as plaintext to the server for authentication with no issues. Every call to the web services re-authenticated the user to make sure they were still allowed to access the requested resource.  The username/passwords were stored on the mobile device in a way that’s inaccessible to the user.

The client wanted these same web services to be used by their web site.  Since storing the username/password in plain text on a desktop computer was no longer an option, the authentication schema needed to be altered.

I tried to get OAuth integrated into our existing solution in order to change the authentication schema to use a bearer token, but for one reason or another I kept running into problems.  My thought process eventually settled on this:
  • The username/password cannot be stored in plain text anymore
  • Every web service request must verify authentication
  • We can still store something client side as long as it’s useless to the client alone
  • Why can’t we generate our own token, since we control both the client and server?
I eventually settled on constructing a string that contains key pieces of information that will be encrypted.  The client will receive this “custom token” and pass it along with every web service request.  The web service will decrypt and deconstruct the token to get critical pieces of info (username, last time authenticated, etc.) and use that to verify that the user has access to the requested resource.  Since the server is the only part of the process that needs to decrypt the token, the client only needs to store the encrypted version of the token, which is useless to any prying eyes.
Another option that seemed just as valid was to encrypt the password on the server and pass that back with the successful authentication message upon login.  This encrypted version of the password would be stored and passed along with every request, so the web service is actually checking the username/password on every request.  I chose to do the custom bearer token idea simply because we’d be able to contain more info within the token.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s