The length extension attack that @Tinned_Tuna talks about would have allowed you to generate forged tokens with a "public text" of your own choosing (within some format constraints due to SHA-256 padding, though), but only if the secret had come first in the hash function. By inputting the secret last, this specific weakness is avoided.
Another, less serious weakness related to the input of the "public text" first is that, potentially, as an attacker, you could try to build a SHA-256 collision, have one message of the colliding pair be authenticated by the key-owner system, and the hash value will be valid for both messages. In other words, using SHA-256(public+secret) makes the algorithm only as strong as collision resistance of the hash function, instead of preimage resistance. This is not a serious problem because SHA-256 has a 256-bit output, which makes it immune (in practice) to collisions; that's more a theoretical issue in that you do not get your money worth (you have to use a 256-bit output to get 128-bit security).
An handwaving way of stating things is that, in such constructions, you need to input the secret key at least twice, at the beginning and at the end of the computation. But, really, you want a MAC; that's what your "tokens" are about. So, do yourself a favour, don't try to invent your own algorithm; instead, use something which has been carefully designed and studied for years, even decades, and provides the kind of security you want. This is called HMAC. HMAC uses an underlying hash function (e.g. SHA-256) but does it well, with the secret key inserted at the right place so as to avoid the tricky pitfalls implied by using an actual hash function, as opposed to the mythical beast known as a "random oracle". If you study HMAC, you will see two nested invocations of the hash function, with the secret key used twice.