Is is possible in Go to access JWT token stored in client localstorage?

I've already implemented a SPA application on the backend and with angular it's easy to authorize the token stored in the browsers localstorage, but on the frontend I use the server for rendering the html.

In go, on the HTTP request handler, from the server, how can I get hold of the browsers localstorage / sessionstorage to retrieve the token, validate it and render the allowed content in the response?

Is this even possible or do I have to use session?

I was thinking maybe somehow the http.client had some way I don't see, which could help get the job done?

edit
If it's not possible I found this: http://www.gorillatoolkit.org/pkg/securecookie - I tried googleing a bit but I want to be absolute certain this hmac verification makes this solution at least as secure as the JSON Web Tokens?

And if there is indeed someone who can come up with good arguments why one should use server resources on session, please do share this with me (I don't care about old browsers btw - only performance and utilizing the clients where possible, as long as security is not compromised)

Some people have downvoted your question, so perhaps it'd be helpful to get things straight:

• Backend is the thing that generates the html and sends it to the user- server-side;
• Frontend is what the end user sees in his/her browser (including javascript) - client-side.
• The browsers localstorage is at the frontend, and is therefore not accessible to the backend. You may use cookies (which are stored on the client-side, but sent to the server-side and vice versa) - but that's about as far as it goes.
• securecookie is a way of storing cookies at the client-side, without anyone being able to alter/view them except yourself - because it's encrypted using a "secret" only you (should) know.
• The advantage of session-data, is that there's no need to verify it for forgery - you're the one that put the data there, and if there's something/someone that did forge the session data, then you've got bigger problems. You may also store things that you don't want the end-user/client to know about. Using encrypted cookies is an alternative to achieve this.
  • Note that you can use session data to store large things as well - if there's a (possibly valid but) strange reason to store a 500MB session data blob for the end-user, you don't want to send that 500MB to the end-user right away. The session data stays at your server.