Skip to content

Conversation

@cristiprg
Copy link
Collaborator

@cristiprg cristiprg commented Jun 23, 2025

This commit updates the views related to device auth flow from
functions to class-based views. This makes it easy to import
them in other projects and only overwrite small bits of functionality
(specifically looking at templates and context_data).

A 3rd view is added for the final step where the user is presented
with the status of the device after they approve or deny.

The views now also have a more "standard" django form behaviour, changes
being relfected in the tests.

Fixes #

Description of the Change

Checklist

  • PR only contains one change (considered splitting up PR)
  • unit-test added
  • documentation updated
  • CHANGELOG.md updated (only for user relevant changes)
  • author name in AUTHORS

duzumaki and others added 30 commits May 19, 2025 11:44
This model represents the device session for the request and response stage
See section 3.1(https://datatracker.ietf.org/doc/html/rfc8628#section-3.1)
and 3.2(https://datatracker.ietf.org/doc/html/rfc8628#section-3.2)
Django represents headers according to the common gateway interface(CGI)
standard. This means it's in all caps with words divided with a hyphen

However a lot of libraries follow the pattern of Something-Something
so this ensures the header is set correctly so libraries like oauthlib
can read it
This method calls the server's create_device_authorization_response method
(https://datatracker.ietf.org/doc/html/rfc8628#section-3.2)

and is returns to the caller the information adhering to the rfc
The device flow is initiated by sending the client_id and and a scope.
This check should not fail if the client is public
OAUTH_DEVICE_VERIFICATION_URI = the uri that comes back from the response
so the user knows where to go to. e.g example.com/device

OAUTH_DEVICE_USER_CODE_GENERATOR = Allows a custom callable to be passed in to control
how the user code is generated, stored in the db and returned back to the caller
DEVICE_MODEL = the device model

DEVICE_FLOW_INTERVAL = The time in seconds to wait before the device should poll again
This view is to be used in an authorization server in order to provide
a /device endpoint
This commit will not be merged(I think).
Currently oauthlib is due a release so I'm pointing this
to master
A public device code grant doesn't have a client_secret to check
It needs handled differently depending on the device grant type or not
it also needs to be rate limited to adhrere to the polling section in the spec
so a device can't spam the token endpoint
This creates a user friendly but still high entropy user code to be used
in the device flow
Tests the device flow end to end
Older version doesn't work with newer version of python
cristiprg added 4 commits June 6, 2025 20:09
In this commit I've addressed a few issues raised in comments about
the flow.

* Always return informative errors to user-facing views. If the device
is not in the expected state, the errors are returned in the form, instead
of raising exceptions.

* Always return JSON response to device-facing view (aka TokenView). If
the device is not in the expected state, the errors are returned according
to the RFC.

* Never involve device_code in frontend. The redirect to device-confirm
view now takes client_id and user_code arguments instead of device_code

* Increased test coverage. Added tests for expected error cases handled
in the code
Perferred to use the Grant suffix in order to keep the naming
consistent with other grant models.
This commit updates the views related to device auth flow from
functions to class-based views. This makes it easy to import
them in other projects and only overwrite small bits of functionality
(specifically looking at templates and context_data).

A 3rd view is added for the final step where the user is presented
with the status of the device after they approve or deny.

The views now also have a more "standard" django form behaviour, changes
being relfected in the tests.
@cristiprg cristiprg force-pushed the add-device-flow-wip-2 branch from dd180ec to 733f7a1 Compare June 23, 2025 16:03
@dopry dopry force-pushed the add-device-flow branch from 824c834 to 8d716e2 Compare June 28, 2025 02:32
@cristiprg cristiprg force-pushed the add-device-flow branch 3 times, most recently from ac159b0 to 74ffed5 Compare August 14, 2025 11:46
@dopry dopry force-pushed the add-device-flow branch 2 times, most recently from 66b02e3 to c10a471 Compare November 3, 2025 03:57
@dopry dopry force-pushed the add-device-flow branch 2 times, most recently from 6dc5041 to 47a35bd Compare November 9, 2025 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants