🚀 Feature: Device Authorization Grant with QR code #562

New Issue

OVERLORD · 2026-02-04T20:28:42+03:00

OVERLORD commented

2026-02-04 20:28:42 +03:00

Originally created by @jonnywright on GitHub (Dec 11, 2025).

Feature description

I will preface this issue with the facts that I am a user of Pocket ID, by no means a developer, and not even a novice when it comes to OIDC / OAuth and the specifications on which they are developed, so my request may not even be possible within the specification. However, I think what I am trying to describe is RFC 8628, with specific emphasis on the "input constrained" element of the standard.

The feature has been posed in a comment in a previous issue (#267), however the issue was closed before the comment was made and I don't feel that the use case was fully understood before it was closed, hence raising it here.

User opens the client (e.g. Home Assistant, Jellyfin) on a device which doesn't support passkeys (e.g. smart TV, in-vehicle web-browser) or is input constrained. User is forwarded to Pocket ID
User selects Sign in with QR code option (which is supplement to the existing Sign in with login code option)
User scans the QR code on a device which supports passkeys, e.g. their smartphone, which forwards the user to Pocket ID with a short-lived code
User authenticates on their compatible device and client (on incompatible device) is successfully logged in

Pitch

I have two specific (albeit edge) cases where this functionality would improve quality of life - I concede that this functionality is already possible using the existing short-code workflow, but implementing this feature would make the expereince more fluid in most cases and improve user experience.

Jellyfin on HDMI TV dongle: when travelling I access my media remotely through Jellyfin. Currently I use the login code method but entering the code into the login screen can be awkward and prone to mistakes. This is particularly annoying on hotel WiFi where inter-device connectivity is blocked, I usually have to enter the code using the remote and the non-qwerty, square on-screen keyboard.
Home Assistant on in-vehicle display: I sometimes access Home Assistant from my in-vehicle display where I have a specific dashboard setup for things like garage door control. Similarly to the previous example, I currently use the login code method which is possible, but isn't a smooth flow.

I do have a few other examples but they make me look even more lazy than I am making myself look.

The current process requires the user to make the following steps:

Open Pocket ID on a compatible device
Authenticate on compatible device
Create login code
Navigate to client on incompatible device
On incompatible device, select Sign in with login code on client
Paste login code and submit

The proposed process would require the user to take the following steps:

Navigate to client on incompatible device which forwards to Pocket ID
On incompatible device, select Sign in with QR code on client
Scan QR code on compatible device, which opens Pocket ID authentication page
Authenticate on compatible device

The proposed alternative is 2 fewer steps (slightly subjective how many, but I'd argue its objectively fewer steps), but regardless of this the interaction required by the user is far more fluid (e.g. no manual code entries).

This example assumes the user typically uses a mobile device as their compatible device and is therefore able to scan the QR code. The proposal is that this feature compliments the existing Sign in with login code feature - not replaces it.

Originally created by @jonnywright on GitHub (Dec 11, 2025). ### Feature description I will preface this issue with the facts that I am a user of Pocket ID, by no means a developer, and not even a novice when it comes to OIDC / OAuth and the specifications on which they are developed, so my request may not even be possible within the specification. However, I _think_ what I am trying to describe is [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628), with specific emphasis on the "_input constrained_" element of the standard. The feature has been posed in a comment in a previous issue ([#267](https://github.com/pocket-id/pocket-id/issues/267#issuecomment-3033113211)), however the issue was closed before the comment was made and I don't feel that the use case was fully understood before it was closed, hence raising it here. 1. User opens the client (e.g. Home Assistant, Jellyfin) on a device which doesn't support passkeys (e.g. smart TV, in-vehicle web-browser) or is input constrained. User is forwarded to Pocket ID 2. User selects _Sign in with QR code_ option (which is supplement to the existing _Sign in with login code_ option) 5. User scans the QR code on a device which supports passkeys, e.g. their smartphone, which forwards the user to Pocket ID with a short-lived code 6. User authenticates on their compatible device and client (on incompatible device) is successfully logged in ### Pitch I have two specific (albeit edge) cases where this functionality would improve quality of life - I concede that this functionality is already possible using the existing short-code workflow, but implementing this feature would make the expereince more fluid in most cases and improve user experience. 1. **Jellyfin on HDMI TV dongle**: when travelling I access my media remotely through Jellyfin. Currently I use the login code method but entering the code into the login screen can be awkward and prone to mistakes. This is particularly annoying on hotel WiFi where inter-device connectivity is blocked, I usually have to enter the code using the remote and the non-qwerty, square on-screen keyboard. 2. **Home Assistant on in-vehicle display**: I sometimes access Home Assistant from my in-vehicle display where I have a specific dashboard setup for things like garage door control. Similarly to the previous example, I currently use the login code method which is possible, but isn't a smooth flow. I do have a few other examples but they make me look even more lazy than I am making myself look. The current process requires the user to make the following steps: 1. Open Pocket ID on a compatible device 2. Authenticate on compatible device 3. Create login code 4. Navigate to client on incompatible device 5. On incompatible device, select _Sign in with login code_ on client 6. Paste login code and submit The proposed process would require the user to take the following steps: 1. Navigate to client on incompatible device which forwards to Pocket ID 2. On incompatible device, select _Sign in with QR code_ on client 3. Scan QR code on compatible device, which opens Pocket ID authentication page 4. Authenticate on compatible device The proposed alternative is 2 fewer steps (slightly subjective how many, but I'd argue its objectively fewer steps), but regardless of this the interaction required by the user is far more fluid (e.g. no manual code entries). This example assumes the user typically uses a mobile device as their compatible device and is therefore able to scan the QR code. The proposal is that this feature compliments the existing _Sign in with login code_ feature - not replaces it.

OVERLORD added the needs more upvotes label 2026-02-04 20:28:42 +03:00

OVERLORD commented

2026-02-04 20:28:53 +03:00

@Norrodar commented on GitHub (Dec 22, 2025):

I’d like to add a "family perspective" to this. For non-technical users, the current manual code process creates significant friction. I often hear questions like: "Why do I have to visit a separate website just to watch Jellyfin?" or "Where am I supposed to enter this code?".

Explaining this process repeatedly is a burden for the person managing the instance. A QR code would make the flow "invisible" and intuitive: they just scan it, tap "Approve" on their phone, and they're in. It would drastically improve the user experience for family members and reduce the support overhead for admins.

@Norrodar commented on GitHub (Dec 22, 2025): I’d like to add a "family perspective" to this. For non-technical users, the current manual code process creates significant friction. I often hear questions like: "_Why do I have to visit a separate website just to watch Jellyfin?_" or "_Where am I supposed to enter this code?_". Explaining this process repeatedly is a burden for the person managing the instance. A QR code would make the flow "invisible" and intuitive: they just scan it, tap "Approve" on their phone, and they're in. It would drastically improve the user experience for family members and reduce the support overhead for admins.

OVERLORD commented

2026-02-04 20:29:00 +03:00

@borsTiHD commented on GitHub (Jan 3, 2026):

I just had the same experience with the Home Assistant App on iOS. I can't use passkeys on that Situation and ended with the "login code", but it would helped here if it has this feature.
I would love to see that implemented.

@borsTiHD commented on GitHub (Jan 3, 2026): I just had the same experience with the Home Assistant App on iOS. I can't use passkeys on that Situation and ended with the "login code", but it would helped here if it has this feature. I would love to see that implemented.

OVERLORD commented

2026-02-04 20:29:03 +03:00

@jonnywright commented on GitHub (Jan 21, 2026):

Looks like its coming in pull https://github.com/pocket-id/pocket-id/pull/1261

@jonnywright commented on GitHub (Jan 21, 2026): Looks like its coming in pull [https://github.com/pocket-id/pocket-id/pull/1261](https://github.com/pocket-id/pocket-id/pull/1261)

OVERLORD commented

2026-02-04 20:29:06 +03:00

@Norrodar commented on GitHub (Feb 3, 2026):

Just letting you know that I'm currently working on this. It's really not an easy task, as it involves more than just "showing a QR code" or "adding 2-3 points to the current flow." I'm testing every possible way to use the QR flow, including auto-redirects when a Smart TV, car, or Xbox is detected. I’m also implementing a way to enter the confirmation code on the settings page instead of scanning the QR code—useful if the passkey device lacks a camera, like a desktop PC.

I am also trying to stay very close to RFC 8628 and other standards while investigating security measures to prevent JWT token theft.

A quick note about my background (for @stonith404): I completed an apprenticeship as a PHP/SQL/Java developer and worked in the field for about 5 years, but that was ~13 years ago. Since then, I’ve done some scripting and small tasks, but no deep development. I’m also not yet familiar with Go or Svelte. To be transparent: I am working on this using Claude Code Opus 4.5. However, I research the RFCs myself and create my own implementation plans before using Claude to generate code snippets. I then check these word-by-word to ensure they are correct.

Testing is entirely my own manual task, and I try to anticipate every possible move a user or system might make. I hope that’s okay with you, @stonith404. My goal is to avoid creating additional work for you, but I would appreciate a deep dive review later on to see if I missed anything or could improve the implementation.

@Norrodar commented on GitHub (Feb 3, 2026): Just letting you know that I'm currently working on this. It's really not an easy task, as it involves more than just "showing a QR code" or "adding 2-3 points to the current flow." I'm testing every possible way to use the QR flow, including auto-redirects when a Smart TV, car, or Xbox is detected. I’m also implementing a way to enter the confirmation code on the settings page instead of scanning the QR code—useful if the passkey device lacks a camera, like a desktop PC. I am also trying to stay very close to [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628) and other standards while investigating security measures to prevent JWT token theft. A quick note about my background (for @stonith404): I completed an apprenticeship as a PHP/SQL/Java developer and worked in the field for about 5 years, but that was ~13 years ago. Since then, I’ve done some scripting and small tasks, but no deep development. I’m also not yet familiar with Go or Svelte. To be transparent: I am working on this using Claude Code Opus 4.5. However, I research the RFCs myself and create my own implementation plans before using Claude to generate code snippets. I then check these word-by-word to ensure they are correct. Testing is entirely my own manual task, and I try to anticipate every possible move a user or system might make. I hope that’s okay with you, @stonith404. My goal is to avoid creating additional work for you, but I would appreciate a deep dive review later on to see if I missed anything or could improve the implementation.

OVERLORD commented

2026-02-04 20:29:16 +03:00

@jonnywright commented on GitHub (Feb 4, 2026):

It's really not an easy task, as it involves more than just "showing a QR code" or "adding 2-3 points to the current flow."

@Norrodar What do you mean it isn't easy? 😉 I joke, of course, and its amazing to hear that someone has a similar use case and has the ability (and willing) to take on something like this. Unfortunately, my development skills are just nowhere near good enough to even consider something like this (even with 🤖 agents assisting me), but I would love to have been able to contribute. I like some of the additional ideas you've had too - like auto-redirection for specific devices.

Thanks for updating and also thanks for giving your time to the project (that goes for @stonith404 too, obviuosly!). People like me (who cannot offer any kind of code contributions) do value the time and effort given by those who can.

@jonnywright commented on GitHub (Feb 4, 2026): > It's really not an easy task, as it involves more than just "showing a QR code" or "adding 2-3 points to the current flow." @Norrodar What do you mean it isn't easy? 😉 I joke, of course, and its amazing to hear that someone has a similar use case and has the ability (and willing) to take on something like this. Unfortunately, my development skills are just nowhere near good enough to even consider something like this (even with 🤖 agents assisting me), but I would love to have been able to contribute. I like some of the additional ideas you've had too - like auto-redirection for specific devices. Thanks for updating and also thanks for giving your time to the project (that goes for @stonith404 too, obviuosly!). People like me (who cannot offer any kind of code contributions) do value the time and effort given by those who can.

OVERLORD commented

2026-02-04 20:29:21 +03:00

@kmendell commented on GitHub (Feb 4, 2026):

Just letting you know that I'm currently working on this. It's really not an easy task, as it involves more than just "showing a QR code" or "adding 2-3 points to the current flow." I'm testing every possible way to use the QR flow, including auto-redirects when a Smart TV, car, or Xbox is detected. I’m also implementing a way to enter the confirmation code on the settings page instead of scanning the QR code—useful if the passkey device lacks a camera, like a desktop PC.

I am also trying to stay very close to RFC 8628 and other standards while investigating security measures to prevent JWT token theft.

A quick note about my background (for @stonith404): I completed an apprenticeship as a PHP/SQL/Java developer and worked in the field for about 5 years, but that was ~13 years ago. Since then, I’ve done some scripting and small tasks, but no deep development. I’m also not yet familiar with Go or Svelte. To be transparent: I am working on this using Claude Code Opus 4.5. However, I research the RFCs myself and create my own implementation plans before using Claude to generate code snippets. I then check these word-by-word to ensure they are correct.

Testing is entirely my own manual task, and I try to anticipate every possible move a user or system might make. I hope that’s okay with you, @stonith404. My goal is to avoid creating additional work for you, but I would appreciate a deep dive review later on to see if I missed anything or could improve the implementation.

Hey @jonnywright Elias has a tight schedule right now , so figured id answer you. The use of AI is okay with us, as long as its a assisted and tested implementation, and not fully vibe coded. We both use AI to help asist in development, or to use for long annoying tasks. Based on your background and explnation , it sounds good to me:). The main thing is complying with the OIDC spec, i was looking it up awhile back there nothing explicit about a QR code in the spec just as long as it contains the verifcation_url if i remember correctly.

@kmendell commented on GitHub (Feb 4, 2026): > Just letting you know that I'm currently working on this. It's really not an easy task, as it involves more than just "showing a QR code" or "adding 2-3 points to the current flow." I'm testing every possible way to use the QR flow, including auto-redirects when a Smart TV, car, or Xbox is detected. I’m also implementing a way to enter the confirmation code on the settings page instead of scanning the QR code—useful if the passkey device lacks a camera, like a desktop PC. > > I am also trying to stay very close to [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628) and other standards while investigating security measures to prevent JWT token theft. > > A quick note about my background (for [@stonith404](https://github.com/stonith404)): I completed an apprenticeship as a PHP/SQL/Java developer and worked in the field for about 5 years, but that was ~13 years ago. Since then, I’ve done some scripting and small tasks, but no deep development. I’m also not yet familiar with Go or Svelte. To be transparent: I am working on this using Claude Code Opus 4.5. However, I research the RFCs myself and create my own implementation plans before using Claude to generate code snippets. I then check these word-by-word to ensure they are correct. > > Testing is entirely my own manual task, and I try to anticipate every possible move a user or system might make. I hope that’s okay with you, [@stonith404](https://github.com/stonith404). My goal is to avoid creating additional work for you, but I would appreciate a deep dive review later on to see if I missed anything or could improve the implementation. Hey @jonnywright Elias has a tight schedule right now , so figured id answer you. The use of AI is okay with us, as long as its a assisted and tested implementation, and not fully vibe coded. We both use AI to help asist in development, or to use for long annoying tasks. Based on your background and explnation , it sounds good to me:). The main thing is complying with the OIDC spec, i was looking it up awhile back there nothing explicit about a QR code in the spec just as long as it contains the `verifcation_url` if i remember correctly.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id#562