Mobile to Server Authentication - Summary

Over the past few articles, I've described the steps required to securely authenticate and communicate between a mobile app and a server. This communication channel will serve as a foundation for much more complex interactions in the future.

Although I've previously emphasized the importance of security, I'll emphasize it again here: If you leak sensitive data, there's no getting it back. So when in doubt, select the option that provides better odds that data won't leak.

Applying this logic to my current solution helps highlight a potential concern: I've stored all of the user tokens "in the clear" - they're not encrypted. So, if a hacker were able to gain access to my underlying database, I could end up with a fairly serious data leak. One solution to this issue would be to provide a salted, one-way hash of the tokens. This approach adds a small amount of overhead, but the payback is significant: If the database was hacked, the tokens would remain unreadable. So to me, it's an easy decision to add this extra level of protection. (The implementation of this functionality is left as an exercise for the reader.)

So we now have a secure channel for communication - that's great! Unfortunately, not much information is actually being communicated. In the next article, I'll beef up the business / data model, and provide additional view controllers for managing the data.