mirror of
https://github.com/pocket-id/pocket-id.git
synced 2025-12-09 14:42:59 +03:00
🚀 Feature: QR Code / 2nd Device / Assisted Sign-In #332
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @acidRain-burns on GitHub.
Feature description
I tried to look up the name for this process, but couldn't find what it would be called beyond just a QR Code sign in, so bear with me:
The pocket-id admin could enable this globally for all OIDC clients, or opt-in individual clients. The user would, when authenticating with approved clients, have the option to complete the request on another device. When that option is selected by the user, pocket-id would present the user with a QR code where the request would already be populated. If the user was already signed in to pocket-id, they would be prompted to approve or deny the sign-in. If they were not yet signed in, they would be requested to sign in first. Ideally, the QR Code URL is just a normal URL that could be typed in as a fallback, maybe something short like pocket-id.example.com/approvals/shortlivedcodehere)
Examples of this:
Pitch
For my use-cases, when using a device that does not support passkeys (TVs, XR Headsets, VMs), it would be appreciated to have the ability to complete the sign-in on your phone (via qr code) or another device (with say, a short-lived code).
@kmendell commented on GitHub:
I will close this issue and we can continue the conversation in #112. Just upvote that issue and add your comments. Thank you!
@penalte commented on GitHub:
Duplicated #112
@acidRain-burns commented on GitHub:
I looked at #112; At the time the scope seemed different enough that this seemed warranted, but maybe I am mistaken. Feel free to close if this is the case. I can also add my thoughts to #112
@kmendell commented on GitHub:
@stonith404 My mistake i thought they were the same thing, sorry for closing that out by accident.
@stonith404 commented on GitHub:
This is not a duplicate of #112 as this issue is meant to directly sign in to Pocket ID. #112 describes a way to authorize an OIDC client that doesn't have a browser built-in.
@acidRain-burns Do you have an actual example where you're currently limited with passkeys? For example I don't really see a reason why you want to sign in to Pocket ID on a tv. Also a VM should support passkeys by using this flow. Or do I miss something?
@Green-Kite commented on GitHub:
I've another example for this use case: Seafile supports SSO login in their desktop and mobile apps. If you click on the SSO Button you'll get directed to the Pocket ID Passkey Login in a built-in browser. If you click on "Don't have access to your passkey?" there and use the Link you get in the email, the system browser gets opened, but you can't login into Seafile as there's no matching between these requests and you're using different browsers.
@stonith404 commented on GitHub:
@acidRain-burns Alright thanks for your explanation. I think this would make sense to implement.
What do you think about #271 , this would also fix this, right? If this PR gets merged you would be able to create a one-time-access link on another device which you then could use to sign in on your TV, XR headset or VM.
@kmendell commented on GitHub:
@stonith404 based on green-kites reply , #271 wouldnt fix his issue, unless im reading it wrong, maybe theres another type of fix that could be implmemeted along side 271.
@acidRain-burns commented on GitHub:
@stonith404 I can think of a few examples right off the bat; I would like to preface this by saying I am probably not representative of a large part of pocket-id users BUT I do think this feature addresses a lot of edge cases, of which mine are a sample. I also acknowledge that there may be ways to technically accomplish a sign in, though they are not at all convenient. Many of my users are passkey-only: for many of the services pocket-id protects, they made an account by signing in to the service via pocket-id, and some have the option to sign in via passwords disabled or the service makes you choose between passkeys and passwords.
@Green-Kite commented on GitHub:
I'm not sure if a simple thing just like "mail a six digit code and enter it on the sign in page" would be possible?
Or maybe sign in on the other browser and click "Yes" somewhere to allow the other request.
@kmendell commented on GitHub:
@Green-Kite what your describing sounds more like the the Device Code Endpoint this is currently in dvelopment here: https://github.com/pocket-id/pocket-id/pull/270 , but still different in ways, so i cant speak for certain if we can do something like that, would have to have stonith review.
@stonith404 commented on GitHub:
v0.37.0allows you now to create a login code in your account settings and use it for signing in.@kmendell commented on GitHub:
@stonith404 Gotcha, The page should be easy to copy, and reusable, i think. Though im not sure the best way to implement this feature, you may have better ideas.
@Green-Kite commented on GitHub:
@stonith404 thx I tried the Seafile SSO login feature and it worked. Would be great to get the code via email too and not just through the UI. But it's great now to have a way for browsers that don't support passkeys or when on devices other than your main one.
@stonith404 commented on GitHub:
@kmendell You're right.
I think @Green-Kite suggestion would make sense. We could just create a page where a user can enter the one-time access token, this would be pretty easy to implement. We could build a similar page to the page you've created in #270. If the code is provided in the URL the user gets signed in automatically or else he can enter it manually. This can actually not be achieved with #270 because the device code endpoint only allows to authorize clients, not to sign in to Pocket ID.
@acidRain-burns commented on GitHub:
I still think this auth flow should work from other direction instead, where the code is presented by the device you want to sign into, not the device you are signed into already/capable of signing into easily.
That said, this definitely works -- thank you sooo much!!!!
@Green-Kite commented on GitHub:
I've played around with it a bit now and found out that the Email Code feature logs you into the Pocket ID web interface instead of redirecting to the service you started the login process with. Is this the behaviour that is intended with this feature?
@stonith404 commented on GitHub:
@Green-Kite This is possible but you have to enable "Email Login Code" in the application configuration.
@kmendell commented on GitHub:
@acidRain-burns What your describing is the device authorization endpoint, which is still in dvelopment here: https://github.com/pocket-id/pocket-id/pull/270
That being said this requires the application to be setup with this functionality as it follows oidc spec. So its a bit different than this feature.
@Green-Kite commented on GitHub:
Sorry I was blind...
I only paid attention to the login code option and ignored the second option after clicking on it haha
@stonith404 commented on GitHub:
This was actually a bug which should be fixed in the latest version.
@Oni commented on GitHub:
So, if I understand this correctly, the flow would be like this:
@Oni commented on GitHub:
Sorry for the bad wording.
What I have described is the workflow proposed here.
The current workflow (see #270) requires you to log in to the pocket-id admin page and generate a code there. You then have to put the code inside the client. In my opinion, the current workflow is counter-intuitive and inconvenient for clients like TVs where the keyboard is far from practical.
@IzeQube commented on GitHub:
But this isn't currently working this way, is it? I don't have any QR code option...
@kmendell commented on GitHub:
Does the same happen if you try without the email code? I think this was the intended use case as it replaced the onetime link. But if the same does not happen with the email version then im not sure..