In order to implement CSRF protection, you need a token that is secret in the sense that it can't be calculated by an attacker. You can use a modification of the encrypted token pattern from the OWASP CSRF cheat sheet.
You can either use a shared secret key between the front-end and back-end or a public/private key, storing the public key on the front-end and the private-key on the back-end. You then encrypt the user ID and timestamp on the front-end to use as your CSRF token and verify it on the back-end. Instead of encryption you can sign the data using an HMAC or a digital signature. All of the options (asymmetric encryption, symmetric encryption, HMAC, and digital signatures) will produce the desired token properties of being easy to verify but effectively impossible to predict.
The OWASP document suggests that you encrypt the user id, timestamp, and a nonce, but I believe that the nonce is unneeded. See this question and the comment on the OWASP discussion page for more information.