mirror of
https://github.com/pocket-id/pocket-id.git
synced 2025-12-09 14:53:00 +03:00
🚀 Feature: Fallback auth? #489
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 @sardaukar on GitHub.
Feature description
This project is really interesting - what's the fallback scenario for lost keys, though?
Pitch
Maybe an email fallback, just until a new key is setup?
@sardaukar commented on GitHub:
@Node815 advertising for other projects on a question specifically about pocket-id is a bit weird
@sardaukar commented on GitHub:
I think the recovery phrase makes sense, kind of life 2FA recovery codes.
About the admin being able to provide a one-time link: what if the admin loses his key? 😄
@stonith404 commented on GitHub:
I think the best fallback option would be to add a second passkey to your account. Additionally, an administrator can provide a one-time access link if needed.
While email might not be the most secure option, I could implement a recovery phrase that users can write down and use to regain access to their accounts.
What do you think? Would a fallback passkey and a one-time access link be sufficient, or would you recommend adding another method, such as a recovery phrase or something else?
@stonith404 commented on GitHub:
@sardaukar I don't see @Node815's comment as an advertisement because KeepassXC and Vaultwarden are a password manager. You can use Vaultwarden to store your passkeys. This is like a backup of your passkeys because they get synced across your devices.
But I still see the need to recover a Pocket ID account because there might be users that only use hardware passkeys and when you lose them you can't access your account anymore.
@Node815 commented on GitHub:
Where this may not be someone's cup of tea, you can install KeepassXC if you want to keep the attack vector closer to home, as in on your trusted home computer, or you can install Vaultwarden (self hosted Bitwarden compatible system), and use the companion browser plugin for either respective app.
Vaultwarden is what I use, so it natively uses the Bitwarden browser plugin which allows you to save passkeys within it. KeepassXC also does this if you turn the option on in the program from what I've tested. Either of these methods would make a good backup passkey in the event of the lost hardware token or key!
@stonith404 commented on GitHub:
@jbalatero No, but an administrator can create a one-time link over the CLI with
docker compose exec pocket-id sh ./scripts/create-one-time-access-token.sh.@stonith404 commented on GitHub:
The problem with getting a one-time-key over email is that it would allow an attacker to sign in to your Pocket ID account if he has access to your email account. This would reduce the security significantly.
I mean in the end it's really rare that you loose your passkey and if you do, you probably have added a second passkey or you can ask the admin to create a one-time-token for you over the UI. If the admin looses the passkeys he could create a one-time-token over the CLI with the
create-one-time-access-token.shscript.I understand this solution may not be the most convenient, but in my opinion, prioritizing security over convenience is essential in an identity provider.
But I'm still open for discussions :)
@cchance27 commented on GitHub:
Just wondering why not allow for users to request a one-time-key from login page for existing email addresses... and when logged in force creation of a passkey
@jbalatero commented on GitHub:
Is it possible for a one-time link to have an option to never expire so I can print it and safe keep it?
@acidRain-burns commented on GitHub:
An admin being able to issue a recovery link to the user's email (timed expirey), and all accounts having a recovery phrase would be awesome. Would like something in the Audit Logs if a recovery link is sent or a recovery phrase is used.
If this was implemented, would we have the option to have keys revoked if the phrase was used? This would help prevent users from keeping keys they lost/can't find attached to their account.
@stonith404 commented on GitHub:
Sorry, the image was overridden. Please use the
stonith404/pocket-id:dev-email-loginimage instead.@cchance27 commented on GitHub:
I mean i can see the case against, but feel like it would make a good option for less-critical use cases or for where hacking isn't a direct issue, for instance i was looking to use this for something internal apps, we don't need to worry about hacking as you'd also have to have hacked our vpn and also the users emails to pull off a breach, so perhaps as an option to enable user one-time key requests with an asterisk or warning bubble/confirmation that enabling does weaken security as an exploited email could leak a connection.
As it is now its cool, and passkeys are basically everywhere, but i've also got to make sure i've idiot proofed things for people and "i forgot my phone how do i get in" is something i've already heard with other deployments of things lol
@samiralam commented on GitHub:
I'm happy to test this out, but it doesn't look like the
stonith404/pocket-id:developmentimage includes the feature. Is that the correct tag to pull?@stonith404 commented on GitHub:
Okay I see your point. If Pocket ID isn't exposed to the internet this feature would make sense.
@stonith404 commented on GitHub:
I've just added the ability to sign in with an email. Would you mind to test out the
stonith404/pocket-id:developmentimage and give me feedback on it?You have to enable the option in the settings:
And then you can click the highlighted button on the sign in page:
@stonith404 commented on GitHub:
@cchance27 Thanks for the feedback. The latest
stonith404/pocket-id:dev-email-loginimage should now correctly redirect users to the client authorization page.@cchance27 commented on GitHub:
Worked fine for me with the latest issues for dealing with more secure environments, the only thing that ... is a little disruptive to flow is...
If i request the code from myapp.mydomain.com and request the code, and then click the email link, it logs me into the pocket-id config section... which is fine for adding a passkey to an existing user which solves the major issue i saw for internal apps...
But realized this workflow does have a bit of a rough edge for UX, user now needs to go type the url they originally wanted to get to again, and somewhat worse it's not exactly idiot proof, as the user that thought they were logging into the internal app is in pocket-id that they likely have no idea about, would be nice if the dashboard had a floating alert at the top, that realized this was a OTT login, and said "Please setup a passkey, and then click here to continue to YYY (domain from original attempt)", could pass the original URL with the OTT to keep the UX flow intact, just an idea, what do you think, i try to think of all the weird edge cases that internal users have for tools like this.