Support verification_url mispelling in the device auth response

[celian-garcia]

Preflight Checklist

• I could not find a solution in the existing issues, docs, nor discussions
• I have joined the ZITADEL chat

Describe your problem

Hello, any chance that this lib would implement this kind of workaround implemented by golang/oauth2:
https://github.com/golang/oauth2/blob/master/deviceauth.go#L58-L78

func (c *DeviceAuthResponse) UnmarshalJSON(data []byte) error {
	type Alias DeviceAuthResponse
	aux := &struct {
		ExpiresIn int64 `json:"expires_in"`
		// workaround misspelling of verification_uri
		VerificationURL string `json:"verification_url"`
		*Alias
	}{
		Alias: (*Alias)(c),
	}
	if err := json.Unmarshal(data, &aux); err != nil {
		return err
	}
	if aux.ExpiresIn != 0 {
		c.Expiry = time.Now().UTC().Add(time.Second * time.Duration(aux.ExpiresIn))
	}
	if c.VerificationURI == "" {
		c.VerificationURI = aux.VerificationURL
	}
	return nil
}

I am implementing a client for google API using zitadel/oidc lib but they are using verification_url instead of uri ...
https://stackoverflow.com/q/76696956/5690223
https://developers.google.com/identity/protocols/oauth2/limited-input-device?hl=fr#success-response

Describe your ideal solution

I have no better solution in head than the workaround described

Version

3.14.0

Additional Context

No response

[muhlemmer]

Hi, no I have nothing against it.

As the oauth2 implementation was released shortly after ours, I was actually thinking if we can somehow reuse some of their definitions and cleanup our code. Perhaps the response object would be a good start.

[celian-garcia]

Indeed the DeviceAuthResponse struct looks very similar with your DeviceAuthorizationResponse and it sounds safe enough to start by leveraging on it. To go further, the whole DeviceAuth method itself would be even interesting to look at and check the differences with your implementation. I'm not sure theyŕe equal but look similar.

[celian-garcia]

I can create a PR just reusing the oauth2.DeviceAuthResponse if you have no objection.

[muhlemmer]

Hi, sorry for the late reply. I gave it another thought:

Changing the response type is a breaking change, and we want to prevent that on v3 / main. I think the best solution is indeed the one you proposed earlier, and then we clean that up and use the oauth2.DeviceAuthResponse in v4 / next branch.

We are open for a PR.

[celian-garcia]

Thanks for the answer, I had the same feeling. I'll do a PR tomorrow ;)

[github-actions]

🎉 This issue has been resolved in version 3.20.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀