It would be nice if our CLI applications didn't have to worry about the mechanics of any OAuth 2.0 flow and could simply receive a session identifier like any other web client.
Describe the Solution You Would Like
The device authorization grant type is specified by RFC 8628. Unlike the client credentials grant type, it is substantially similar to the authorization code exchange grant type. The response will contain a refresh token and access token. Our creds endpoints already support the two other common types, authorization_code and refresh_token, implicitly. Therefore, I propose that we make the grant type an explicit parameter on this endpoint and support the following types:
grant_type=refresh_token (current behavior if refresh_token is specified, would be implicit in this case)
grant_type=urn:ietf:params:oauth:grant-type:device_code (new type)
For grant_type=urn:ietf:params:oauth:grant-type:device_code, we perform the following:
If a device_code is not specified, we request a new device code. The provider must be able to provide a device authorization endpoint (similar to the auth code URL). The write operation will return the verification URL and code for the end user to follow. This gives us a device code so we can now proceed regardless.
We set up a poll operation at the requested interval to check for the device flow to complete. Then we return a successful response to the write.
In the meantime, read operations will return a temporarily-unavailable status code for the credential.
When the polling operation reaches any terminal state (expiration, valid creds, etc.) the read will start to return a permanent response, either an access token or the respective error.
If a valid credential contains a refresh token, we store it too and it will automatically be refreshed as needed.
Use Case
It would be nice if our CLI applications didn't have to worry about the mechanics of any OAuth 2.0 flow and could simply receive a session identifier like any other web client.
Describe the Solution You Would Like
The device authorization grant type is specified by RFC 8628. Unlike the client credentials grant type, it is substantially similar to the authorization code exchange grant type. The response will contain a refresh token and access token. Our
creds
endpoints already support the two other common types,authorization_code
andrefresh_token
, implicitly. Therefore, I propose that we make the grant type an explicit parameter on this endpoint and support the following types:grant_type=authorization_code
(current default behavior)grant_type=refresh_token
(current behavior ifrefresh_token
is specified, would be implicit in this case)grant_type=urn:ietf:params:oauth:grant-type:device_code
(new type)For
grant_type=urn:ietf:params:oauth:grant-type:device_code
, we perform the following:device_code
is not specified, we request a new device code. The provider must be able to provide a device authorization endpoint (similar to the auth code URL). The write operation will return the verification URL and code for the end user to follow. This gives us a device code so we can now proceed regardless.Additional Context