Describe the bug

When using the deviceflow with an external auth server, flytectl repeats the device flow each time it is used because it thinks the token is expired. Tracing through the code, I found this is probably the cause. The api response schema, notably has an expires_in not an expiry field. When unmarshalling to an oauth2.Token, it omits the missing expiry and sets the expiry to 0001-01-01T00:00:00Z, which you can verify by looking in your keyring keyring get flytectl 'dns:///<your-endpoint>:flytectl-user'. This causes the future invocations of flytectl to think the token is expired and restart the device flow.

Expected behavior

The stored token should have the expiry date computed from the optional expires_in response from the /token api.

Additional context to reproduce

1. Configure flytectl to use authType: DeviceFlow and point to an endpoint that has auth enabled
2. Run flytectl version
3. Complete device auth flow
4. Run flytectl version again, notice you need to redo the device auth flow
5. Inspect contents of keyring and note the expiry date is the zero value of time.Time

Screenshots

No response

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes