The last time I implemented security, I used Apache Shiro. It provided a reliably secure method of implementing a secured client/server access to user data. Not only did it supply the hashing and crypto algorithms to ensure clear text passwords were not available, it also gave you a framework in which to use your security system. Each component could verify the current user's authentication level, and then allow/disallow various components to be delivered to the user.
I integrated with a GWT application which allowed for local user accounts, facebook accounts, twitter, linkedin, plaxo, and google+. It handled all cases without problems.
When Shiro integrates with your web application, it uses your server-side session to store an identifier for the current user. This is only assigned into the server-side variable when a client successfully provides valid authentication. They also implement a configurable timeout to restrict how long that authentication is good for.
One thing they can't protect is a man in the middle attack, but it isn't your position to secure against that kind of attack. Force the use of SSL, and you've covered your ass.
Check out this list of top 10 security risks as a primer.
As far as how that applies to your own client application, you will inherently be insecure. Typically, you would put a unique code within your application to allow only that application to communicate with your web service. Once one person downloads the client, that code is easily available. Any packet sniffer will be able to see the communications. Use SSL, and it's more difficult, but a decompile will provide the text.
If you restrict access to users that authenticate via your web service, then you're a good step closer.