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

Support RFC 8628 Device Authorization Grant #36

Closed
impl opened this issue Feb 21, 2021 · 2 comments · Fixed by #37
Closed

Support RFC 8628 Device Authorization Grant #36

impl opened this issue Feb 21, 2021 · 2 comments · Fixed by #37
Labels
enhancement New feature or request

Comments

@impl
Copy link
Member

impl commented Feb 21, 2021

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

@impl impl added the enhancement New feature or request label Feb 21, 2021
@impl impl changed the title Support RFC 8626 Device Authorization Grant Support RFC 8628 Device Authorization Grant Feb 21, 2021
@DrDaveD
Copy link
Contributor

DrDaveD commented Feb 23, 2021

Note that I have a vault-plugins-auth-jwt pull request that implements this for that plugin.

@impl
Copy link
Member Author

impl commented Feb 23, 2021

Nice! That will be very helpful as a reference at a minimum. Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants