jwtauth.Verifier fail

I'm trying to implement jwtauth but when the verify jwtoken is supposed to be activated a weird error happens.

So, as in the example they provide, we generate and return a token this way:
<!-- language: lang-go -->

func (s *Service) loginEmployer(w http.ResponseWriter, r *http.Request) {
u := &User{}

	hashed, err := bcrypt.GenerateFromPassword([]byte(r.FormValue("password")), 8)
	if err != nil {
		panic(err)
	}

	tokenAuth = jwtauth.New("HS256", []byte(hashed), nil)
	_, tokenString, _ := tokenAuth.Encode(jwtauth.Claims{"login": r.FormValue("login")})
	u.TokenString = tokenString
	WriteJSON(w, u, 200)
} else {
	http.Error(w, http.StatusText(http.StatusUnauthorized), http.StatusUnauthorized)
}
}

The jwtauth.Verifier is declared as in the doc, global variable.

<!-- language: lang-go -->

var tokenAuth *jwtauth.JwtAuth

func routes(s *Service) *chi.Mux {
// Private access login
r.Group(func(r chi.Router) {
	r.Use(jwtauth.Verifier(tokenAuth))
	r.Use(jwtauth.Authenticator)
	r.Mount("/employer", employerRoutes())
...

But when I try to access the routes within /employer,
I get this error:

2017/07/19 18:16:22 http: panic serving 127.0.0.1:59856: runtime error: invalid memory address or nil pointer dereference
goroutine 15 [running]:
net/http.(*conn).serve.func1(0xc420019680)
    /usr/lib/go-1.8/src/net/http/server.go:1721 +0xd0
panic(0x7f9620, 0xa64510)
    /usr/lib/go-1.8/src/runtime/panic.go:489 +0x2cf
github.com/go-chi/jwtauth.(*JwtAuth).Decode(0x0, 0xc420192707, 0x67, 0x6, 0x6e, 0x0)
    /home/antiaskid/go/src/github.com/go-chi/jwtauth/jwtauth.go:168 +0x40
github.com/go-chi/jwtauth.VerifyRequest(0x0, 0xc4201aa400, 0xc420180b10, 0x1, 0x1, 0x0, 0x1, 0xc420180f30)
    /home/antiaskid/go/src/github.com/go-chi/jwtauth/jwtauth.go:124 +0x154
github.com/go-chi/jwtauth.Verify.func1.1(0xa40920, 0xc4201a8380, 0xc4201aa400)
    /home/antiaskid/go/src/github.com/go-chi/jwtauth/jwtauth.go:79 +0x89
net/http.HandlerFunc.ServeHTTP(0xc4201ae5c0, 0xa40920, 0xc4201a8380, 0xc4201aa400)
    /usr/lib/go-1.8/src/net/http/server.go:1942 +0x44
github.com/go-chi/chi.(*ChainHandler).ServeHTTP(0xc4201ae600, 0xa40920, 0xc4201a8380, 0xc4201aa400)
    /home/antiaskid/go/src/github.com/go-chi/chi/chain.go:29 +0x52
github.com/go-chi/chi.(*Mux).routeHTTP(0xc420192150, 0xa40920, 0xc4201a8380, 0xc4201aa400)
    /home/antiaskid/go/src/github.com/go-chi/chi/mux.go:415 +0x26d
github.com/go-chi/chi.(*Mux).(github.com/go-chi/chi.routeHTTP)-fm(0xa40920, 0xc4201a8380, 0xc4201aa400)
    /home/antiaskid/go/src/github.com/go-chi/chi/mux.go:351 +0x48
net/http.HandlerFunc.ServeHTTP(0xc4201808a0, 0xa40920, 0xc4201a8380, 0xc4201aa400)
    /usr/lib/go-1.8/src/net/http/server.go:1942 +0x44
main.(*Service).sessionMiddleware.func1(0xa40920, 0xc4201a8380, 0xc4201aa300)
    /home/antiaskid/go/src/bitbucket.org/victoria/middlewares.go:17 +0x148
net/http.HandlerFunc.ServeHTTP(0xc4201824e0, 0xa40920, 0xc4201a8380, 0xc4201aa300)
    /usr/lib/go-1.8/src/net/http/server.go:1942 +0x44
github.com/go-chi/chi.(*Mux).ServeHTTP(0xc420192150, 0xa40920, 0xc4201a8380, 0xc42000b000)
    /home/antiaskid/go/src/github.com/go-chi/chi/mux.go:80 +0x1df
net/http.serverHandler.ServeHTTP(0xc4201980b0, 0xa40920, 0xc4201a8380, 0xc42000b000)
    /usr/lib/go-1.8/src/net/http/server.go:2568 +0x92
net/http.(*conn).serve(0xc420019680, 0xa41020, 0xc420017300)
    /usr/lib/go-1.8/src/net/http/server.go:1825 +0x612
created by net/http.(*Server).Serve
    /usr/lib/go-1.8/src/net/http/server.go:2668 +0x2ce

Their example works fine, but the init is always happening. It's written that the Verify will take the token out of the header request as "Authorization", if I remove the verify and check the header, the token + header name are present (r.Header.Get("Authorization"))

Any has an idea about how to have it working?

The problem I am seeing , which I may be incorrect, you are creating tokenAuth for each user that is logging in. There should be one instance of tokenAuth and you encode and decode using that instance. I believe the sign key should be the same for all the users, so you can verify from the tokenAuth instance. You might also want to look into signing it with RS256, because of issues in the past with HS256.

https://auth0.com/blog/brute-forcing-hs256-is-possible-the-importance-of-using-strong-keys-to-sign-jwts/