Assigned
Status Update
No update yet.
Comments
ha...@google.com
I have forwarded this request to the engineering team. We will update this issue with any progress updates and a resolution.
Best Regards,
Josh Moyer
Google Cloud Platform Support
Best Regards,
Josh Moyer
Google Cloud Platform Support
al...@gmail.com
This is not only useful for IP addresses, but also for many other resources. I understand that names are currently used as identifiers, so this request is probably not trivial to implement. Maybe distinguishing between a (numeric, automatically generated) identifier and a (textual) label is the way to go?
Description
I'm currently doing some experiments with the OAuth2 protocol, and I have noticed that Google's OAuth2 implementation (in particular: the device grant described in RFC8628) is not implemented according to the specification.
The usage of the API I'm talking about is specified on this help page:
The JSON example under "Step 2: Handle the authorization server response" shows what the server returns when the client asks for a new device/user code. This example corresponds indeed with what the server returns, but the JSON result does not follow the RFC guidelines. In particular: Google returns the JSON tag "verification_url", while the RFC standard specifies that "verification_uri" should be returned (notice the different letter at the end: L versus I ). The RFC also specifies that "verification_uri" is a required parameter.
As a result, any standards-compliant OAuth2 client will not work with Google's implementation of the Device Grant (they will see that "verification_uri" is missing, a will not be able to send the client to the correct link).
As a solution, I propose to add the "verification_uri" parameter to the JSON result (and keep the old "verification_url" as well). This ensures that your implementation is standards-compliant, but maintains backwards compatibility with clients that rely on "verification_url".
Regards,
Pieter