This repository was archived by the owner on Nov 18, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 13
This repository was archived by the owner on Nov 18, 2024. It is now read-only.
Support RFC 8628 Device Authorization Grant #36
Copy link
Copy link
Closed
Labels
enhancementNew feature or requestNew feature or request
Description
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
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=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:
- 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.
Additional Context
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request