Go Authorization: Scoped API not working

JWT.io
, , ,
1

I have been working through the Authorization documentation for Go (Auth0 Go API SDK Quickstarts: Authorization) as I would like to have a set of private Go APIs and integrate this with Vue SPA. It is necessary that these APIs are scoped and when I got to this section within the documentation, this is where things stopped working.

In the code the checkScope function is called

token, error := jwt.ParseWithClaims(tokenString, &CustomClaims{}, func (token *jwt.Token) (interface{}, error) {

An error is returned:

json: cannot unmarshal array into Go struct field CustomClaims.aud of type string

This seems to be caused, because it expects a string instead of an array for ā€˜audā€™.
So the questions I have are:

  1. Is there always an array returned?
  2. How is it possible to get this to work?
  3. Is it just a bug within the jwt-go module? If so, what other approach should be used? (Documentation update?)

Thanks in advance

3

Hi @mattwatson,

Welcome to the Community!

Can you look at the aud claim and tell us what it is (or an example)?

4

Hi Dan,

Thanks for responding.

So hereā€™s part of the token with aud as an array with some additional information about scope.

map[aud:[https://xxxxxxx.xxxx.xxx https://xxxxxx.us.auth0.com/userinfo] iss:https://xxxxxx.us.auth0.com/ permissions:[read:totals] scope:openid profile email read:totals]

From what Iā€™ve read online, the unmarshal error arises from ParseWithClaims expecting a string value for aud which is part of the jwt-go module (ParseWithClaims: getting json error when processing JWT that has multiple values for audience Ā· Issue #348 Ā· dgrijalva/jwt-go Ā· GitHub). Unfortunately there is no official release to fix this problem and so this complicates matters unless we move to more ā€œup-to-dateā€ forks of the module (GitHub - form3tech-oss/jwt-go: ARCHIVED Golang implementation of JSON Web Tokens (JWT). This project is now being maintained at: https://github.com/golang-jwt/jwt).

Thanks

5

Iā€™m not sure there is much we can do on our side if that is the case. It seems to be more on the side of the module. Let us know if there is anything else we can do.

6

As a bare minimum, it would be helpful to update the documentation to warn those about the problem. However, surely this is a fairly normal use case (SPA with private API)? I guess there arenā€™t as many people using golang as their backend API

7

It looks like you submitted an issue to the quickstart on github, which is perfect. The SDK team should handle it from there. Their response might have been a bit delayed because of the holidays, but they should reach out soon. If they donā€™t let me know and I will ping them.