Unmarshal expires_in outside of oauth2/internal

[andig]

Some almost-OAuth2 apis return expires_in as part of their token response. Unfortunately, unmarshaling into an oauth2.Token does not populate it's Expiry field. Hence, the token structure needs be duplicated/embedded to provide this logic. It would be nice if oauth2.Token.UnmarshalJSON populated the Expiry field when expires_in is populated.

[zak905]

Good point. I mentionned something about it in my latest post: http://www.zakariaamine.com/2021-03-23/leveraging_oauth2_package_golang

This logic here https://github.com/golang/oauth2/blob/master/internal/token.go#L262 needs to be duplicated:

		e := vals.Get("expires_in")
		expires, _ := strconv.Atoi(e)
		if expires != 0 {
			token.Expiry = time.Now().Add(time.Duration(expires) * time.Second)
		}

However, nothing garantees that the time you (as a user) unmarshall a token, is the exact time of the token obtention. This can lead to Expiry field being inaccurate. I guess this is why they kept it internally, because they populate Expiry right after receiving the token, and therefore the Valid() check is correct.

[andig]

Imho that‘s a smaller concern, addressable via docs, and already true with the internal handling today.

[andig]

This is one of the patterns that seems to come up a lot: https://cs.github.com/?scopeName=All+repos&scope=&q=language%3Agolang+ExpiresIn+int#.

An alternative way of achieving the same result could be using

oauth2/internal/token.go

Line 188 in 9780585

func RetrieveToken(ctx context.Context, clientID, clientSecret, tokenURL string, v url.Values, authStyle AuthStyle) (*Token, error) {

.

[zak905]

unforutnately anything under /internal/ cannot be exported and used by other librairies (as per Go specs)

[hickford]

Fixing this would surely break backwards compatibility? Nevertheless easy marshalling between oauth2.Token and RFC 6749 Access Token Response JSON is desirable. Maybe this has to wait until the next major version?

[andig]

Migrated to golang/go#61417