These user tokens you need sure sound a lot like cookies ;-)
Handling cookies is a hairy issue, and there's several approaches.
A usual one is a simple random string of characters. The user keeps it and you validate it against a hash in your database. Leaking this string would be really bad, be careful.
There's a common variation of this one: instead of a random string encode the user id and other session data and sign it (cryptographically), when the user presents it validate the signature and use the data from the cookie itself. This saves you a trip to the database.
A favorite of mine for native clients: HMAC tokens. You share a secret key with the client. The client uses this key to hash a nonce and a timestamp and sends the hash, the nonce and the timestamp to the server. The server performs the same calculations to validate the value received by the client.
This way the secret is sent over the wire only once, reducing risk of leakage. Well implemented it also reduces risk of replay attacks.
There's others. Perhaps you framework already supports one of them, in that case you might be better of with it.
Evaluate the different alternatives and if you need help deciding ask us.