Assigned
Status Update
Comments
ha...@google.com <ha...@google.com> #2
Running into a similar issue, any update on this?
al...@gmail.com <al...@gmail.com> #3
This is a platform behavior change.
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