support provider device_authorization_endpoint

[cbodonnell]

DeviceAuthURL was added to oauth2.Endpoint in golang.org/x/oauth2 v0.13.0

This PR adds support for parsing the provider device_authorization_endpoint from the OIDC discovery endpoint and populates DeviceAuthURL for the oauth2.Endpoint returned by Provider.Endpoint().

Related issue: #357

[somersf]

Device code flow support, and the additional DeviceAuthURL field in Endpoint finally merged into golang.org/x/oauth2 @ v0.13.0.

Perhaps this PR could be updated and made ready for review by the package maintainers?

Some mini comments:

The "coreos/cbodonnell" search/replace in README.md, go.mod, example/{idtoken,userinfo}/app.go, and test should't be part of the PR.

I'd be inclined to update go.mod to depend golang.org/x/oauth2 v0.13.0, and to
update oidc/oidc.go func (p *Provider) Endpoint() oauth2.Endpoint { to have it initialize the DeviceAuthURL field; that way it's auto-populated in the Endpoint for any existing code using Provider.Endpoint() - though I'm not sure if the package maintainers would agree or not...

Thanks!

[ericchiang]

I don't see device_authorization_endpoint as a field provided by OpenID Connect discovery https://openid.net/specs/openid-connect-discovery-1_0.html

Is there another spec I should be looking at?

[ericchiang]

An to be clear, you can retrieve any additional discovery fields through https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc#Provider.Claims

So users can already access device_authorization_endpoint if a provider returns it today

[somersf]

I don't see device_authorization_endpoint as a field provided by OpenID Connect discovery https://openid.net/specs/openid-connect-discovery-1_0.html

Is there another spec I should be looking at?

RFC-8628: OAuth 2.0 Device Authorization Grant -(section 4) defines device_authorization_endpoint, and says it can optionally be included in RFC-8414: OAuth 2.0 Authorization Server Metadata. The latter RFC's introduction says: This specification generalizes the metadata format defined by "OpenID Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible with OpenID Connect Discovery while being applicable to a wider set of OAuth 2.0 use cases.

So, whilst device_authorization_endpoint might not be specifically mentioned in an OIDC specification, it can be included/found in .well-known/openid-configuration - for example see the final paragraph of RFC-8414: OAuth 2.0 Authorization Server Metadata - Section 3 says: Some OAuth applications will choose to use the well-known URI suffix "openid-configuration". As described in Section 5, despite the identifier "/.well-known/openid-configuration", appearing to be OpenID specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.

I also felt that because go-oidc's Provider.Endpoint() populates an oauth2.Endpoint, that it should ideally populate all of the fields in the oauth2.Endpoint. If go-oidc had instead defined/populated its own Endpoint type, I wouldn't have felt that way, as it would have been something independent of the oauth2 struct / OIDC spec-defined only.

Hope that helps.

[somersf]

An to be clear, you can retrieve any additional discovery fields through https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc#Provider.Claims

So users can already access device_authorization_endpoint if a provider returns it today

Yes, thanks, I was aware that it could be extracted this way. I've tried to provide some references / perspective as to why I felt it should be filled out by Endpoint() (now that it is part of oauth2.Endpoint) in my reply to your first comment #365 (comment)

[cbodonnell]

Thanks @somersf - I see both sides here since it's technically not part of the OIDC spec, but I also see how it fits in given the change to oauth2.Endpoint. I'll rebase this PR and address your comments in #365 (review) this week and we can go from there.

[cbodonnell]

@somersf the PR has been updated.

@ericchiang Let us know if this is something reasonable for this project based on the thoughts above. If not, I'd suggest we add a small snippet to the linked issue with the recommended way to retrieve this information for reference.

[somersf]

Thanks for the updates - LGTM. It's over to the project maintainers for their say though!

[ericchiang]

lgtm, can you please squash and resolve conflicts? Also do we need to update our go.mod to support newer versions of oauth2 with the added endpoint field?

[cbodonnell]

lgtm, can you please squash and resolve conflicts? Also do we need to update our go.mod to support newer versions of oauth2 with the added endpoint field?

@ericchiang done! the go.mod is already on the latest version v0.13.0 of golang.org/x/oauth2 as of 3ebd0c9, so we are good there.

[cbodonnell]

@ericchiang anything else we need to do for this one based on my last comment?

[ericchiang]

Sorry for the delay here! lgtm