Skip to content
This repository was archived by the owner on Nov 18, 2024. It is now read-only.
This repository was archived by the owner on Nov 18, 2024. It is now read-only.

Support RFC 8628 Device Authorization Grant #36

@impl

Description

@impl

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 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:

  1. 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.
  2. 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.
  3. In the meantime, read operations will return a temporarily-unavailable status code for the credential.
  4. 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.
  5. 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

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions