Websocket Security
I agree with the SSL/TLS wss:// connection. Always use encrypted traffic. There are several ways to implement a authentication. See here: http://simplyautomationized.blogspot.com/2015/09/5-ways-to-secure-websocket-rpi.html
Most to all examples use python or nodejs and are directed for the Raspberry Pi but the general concepts are good ideas to consider. There are links in the post to a SocketRocket helper library that allows you to insert authentication into the auth header (SocketShuttle).
To secure your messages, use WebSockets over SSL/TLS (wss:// instead of ws://). Don't roll your own crypto.
Concerning authentication. The big difference between HTTP and WebSockets is that HTTP is a stateless protocol and WebSockets is not.
With HTTP you have to send headers (cookies, tokens, whatever) with each request. With WebSockets you establish a connection. In the first interactions you can authenticate the client and for the remainder of the connection you know the client is authenticated.
The people at Heroku have described a pattern where the client authenticates using HTTP, gets a ticket and then sends that ticket as a first message over the WebSocket connection. See https://devcenter.heroku.com/articles/websocket-security
Having secure communication with server includes authenticating both parties to each other. If you need to channel different users with different authentication credentials through one communication channel (which is a rare idea nowadays), you'll need separate authentication. Otherwise, you just need to come up with key distribution scheme (so that your apps know public keys of your server and your server has a protocol of getting acquanted to public keys of clients, there are plenty of patterns for this).
To do that, there is a choice gradient a bit wider than SSL or your own crypto (try to avoid writing your own crypto at any cost).
For webserver-to-browser part of stack, SSL is your only choice, however it shouldn't be considered as a good safety measure, each year unfolds more and more vulnerabilities, cipher degradation cases and trust problems. It carries 20 years of baggage of bad engineering decisions and urgent fixes, so if you can get something better - it's worth doing so. Still, it's much better than nothing for the regular webs.
In your mobile app you could easily use one of a number of cryptographic libraries providing secure session messaging with server with significantly higher security guarantees, no reliance:
https://github.com/mochtu/libsodium-ios, libsodium-ios, an ios wrapper for NaCl, one of the best modern cryptographic libraries, which has lots of novel implementations to ECC cryptography, is highly praised in academic circles and written by a madman keen to have best performance under all circumstances (in short: I adore it :) ).
Themis, a project I'm a contributor in, we have very ObjC-friendly iOS version of our library, and a handy tutorial on doing secure traffic over websockets in iOS: https://www.cossacklabs.com/building-secure-chat