idtoken: provide option to validate token despite being expired

[agusterodin]

Is your feature request related to a problem? Please describe.
I am implementing a refresh token endpoint. In order to decide what refresh token I should give out I first want to check the attached bearer token. I want to determine whether the bearer token is valid (properly signed but doesn't matter if expired or not) and want to be able to access the token's claims (particularly sub so I know which user it is). Right now an expired but validly signed token will completely fail and return an error.

Describe the solution you'd like
An boolean parameter for the idtoken.Validate function for allowExpired. Either that or a parameter that allows you to define an object where you describe the validation steps you want to "opt-out" of / ignore.

I think the allowExpired solution would be a lot simpler.

Describe alternatives you've considered
Implementing token validation and parsing entirely by myself which seems very difficult and leaves a lot of room for potential security holes / missed validation checks.

Additional context
N/A

[codyoss]

Hey @agusterodin thanks for the feature request. I don't believe any of our language libraries allow this kind of flexibility around omit to validate the expiry of a token as it is critical to make sure the token is active to prevent misuse of old tokens. I will do some double checking but I think it is likely we will not move forward with this proposal at this time. In the meantime I would just vendor the library and refactor out expire check. The parsed token returned by the method will allow additional validations.

[agusterodin]

Understandable. Much appreciated!

[agusterodin]

Out of curiosity, what is your official suggestion on how to handle refresh token endpoint logic (checking whether or not previous token was valid)?

Also I agree with you that maximum security should always be there by default. Definitely if the user didn't supply a boolean to skip expiry check I would default to enforcing expiry.

Will vendor for now. Hope that this sort of thing makes its way to this library (or a viable alternative) in the future!

[agusterodin]

Hey, I tried vendoring the library (https://github.com/agusterodin/google-api-go-client) by commenting out the offending lines.

Unfortunately when I run go get github.com/agusterodin/google-api-go-client the terminal just hangs indefinitely. I have a suspicion it is related to this library being so big or having so much history.

My second attempt involved stripping the repository down to just the idtoken folder contents (https://github.com/agusterodin/google-idtoken). Unfortunately it gave me this error, not to mention that updating my fork will be a lot more difficult since the repositories have a completely different structure:

go: downloading github.com/agusterodin/google-idtoken v0.0.0-20211206003719-8bc73e1e950e
package github.com/agusterodin/google-idtoken
        ../../../go/pkg/mod/github.com/agusterodin/google-idtoken@v0.0.0-20211206003719-8bc73e1e950e/compute.go:15:2: use of internal package google.golang.org/api/internal not allowed

Any suggestions?

[codyoss]

The internal folders are where a lot of auth layer stuff happens. You are getting the error because you can't call code from another projects internal folder. You would need to have that copied over as well.