Add instructions in the test IDP for device authorization flow

This commit updates the test IDP fixture seed file with a new Device
Flow OAuth application and updates the Readme with the corresponding
instructions.

The device flow does not really have a RP application, since the device
itself is a RP, therefore used curl commands as an equivalent for PR.

Author: cristiprg

tests/app/README.md

@@ -4,6 +4,8 @@ These apps are for local end to end testing of DOT features. They were implement
 local test environments. You should be able to start both and instance of the IDP and RP using the directions below, then test the
 functionality of the IDP using the RP.
 
+The IDP seed data includes a Device Authorization OAuth application as well.
+
 ## /tests/app/idp
 
 This is an example IDP implementation for end to end testing. There are pre-configured fixtures which will work with the sample RP.
@@ -33,6 +35,36 @@ password: password
 python -Xutf8 ./manage.py dumpdata -e sessions  -e admin.logentry -e auth.permission -e contenttypes.contenttype -e oauth2_provider.accesstoken  -e oauth2_provider.refreshtoken -e oauth2_provider.idtoken --natural-foreign --natural-primary --indent 2 > fixtures/seed.json
 ```
 
+### Device Authorization example
+
+For testing out the device authorization flow, we don't really need a RP, as the device itself
+is the "relying party". The seed data includes a Device Authorization Application, meaning
+you could directly start the device authorization flow using `curl`. In the real world, the device
+would be sending these request that we send here with `curl`.
+
+_Note:_ you can find these `curl` commands in the Tutorial section of the documentation as well.
+
+```sh
+# Initiate device authorization flow on the device; here we use the client_id
+# of the Device Authorization App from the seed data.
+curl --location 'http://127.0.0.1:8000/o/device-authorization/' \
+    --header 'Content-Type: application/x-www-form-urlencoded' \
+    --data-urlencode 'client_id=Qg8AaxKLs1c2W3PR70Sv5QxuSEREicKUlf83iGX3'
+```
+
+Follow the `verification_uri` from the response (should be similar to http://127.0.0.1:8000/o/device"),
+enter the user code, approve, and then send another `curl` command to get the token.
+
+```sh
+curl --location 'http://localhost:8000/o/token/' \
+    --header 'Content-Type: application/x-www-form-urlencoded' \
+    --data-urlencode 'device_code={the device code from the device-authorization response}' \
+    --data-urlencode 'client_id=Qg8AaxKLs1c2W3PR70Sv5QxuSEREicKUlf83iGX3' \
+    --data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:device_code'
+```
+
+The response should include the access token.
+
 ## /test/app/rp
 
 This is an example RP. It is a SPA built with Svelte.

tests/app/idp/fixtures/seed.json

@@ -34,5 +34,26 @@
     "algorithm": "RS256",
     "allowed_origins": "http://localhost:5173\r\nhttp://127.0.0.1:5173"
   }
+},
+{
+  "model": "oauth2_provider.application",
+  "fields": {
+    "client_id": "Qg8AaxKLs1c2W3PR70Sv5QxuSEREicKUlf83iGX3",
+    "user": [
+      "superuser"
+    ],
+    "redirect_uris": "",
+    "post_logout_redirect_uris": "",
+    "client_type": "public",
+    "authorization_grant_type": "urn:ietf:params:oauth:grant-type:device_code",
+    "client_secret": "pbkdf2_sha256$870000$x1A7AKB9YMmNX7v2otXt1C$Yxucj9o/QlF16AxqN5LXo+Se0Sy3FO5x4Q35Lw1FGqM=",
+    "hash_client_secret": true,
+    "name": "Device Authorization App",
+    "skip_authorization": false,
+    "created": "2025-11-07T16:56:23.156Z",
+    "updated": "2025-11-07T16:56:23.156Z",
+    "algorithm": "",
+    "allowed_origins": ""
+  }
 }
 ]