mirror of
https://github.com/pocket-id/pocket-id.git
synced 2026-02-05 00:39:38 +03:00
🚀 Feature: option to require reauthentication for pocket id #535
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 @James18232 on GitHub (Nov 7, 2025).
Feature description
Request to add a feature to enable ‘requires reauthentication’ for pocket id.
This option is available for clients, but not pocket id itself.
Pitch
Pitch: this is a handy feature to extend.
@stonith404 commented on GitHub (Nov 7, 2025):
Can you elaborate? Can't you just reduce the session duration of Pocket ID?
@James18232 commented on GitHub (Nov 7, 2025):
The concept is to keep the session duration longer for use with clients, but not pocket id. So a user can sign in to clients as needed/wanted, but access to pocket id requires reauthentication.
@ItalyPaleAle commented on GitHub (Nov 9, 2025):
Would #1056 be related to this? Maybe with an extra option to configure the session duration for the tokens for Pocket ID itself?
@James18232 commented on GitHub (Nov 9, 2025):
No it is not. The concept is to prove (or re-prove) ownership of a passkey before access to pocket id. Session durations are not related to this. Hope that makes sense..
@ItalyPaleAle commented on GitHub (Nov 9, 2025):
Well, if we limit the duration of sessions for the tokens to Pocket ID itself, that would cause users needing to re-authenticate with the passkey, right?
#1056 is about the tokens issued to clients/apps, which are limited to 1 hour
I also just realized that for the duration of the session to pocket ID, that is currently configured with the "Session Duration" in Pocket ID's config:
If you bring it down to 10 minutes, users will need to use the passkey every 10 mins. Unless I'm mistaken...
@James18232 commented on GitHub (Nov 9, 2025):
You are not mistaken, but that is a different function/feature to my request (i think).
My understanding is currently users can log in to (any) client, and anyone who is able to steal the session cookie via various means could log straight into the users idp and (for example) create a new passkey without ever being challenged.
This is a fringe but problematic scenario that is fixed by treating idp access as untrusted till challenged. A smaller session duration lowers the risk but does not remove it. No proof of ownership, no access to the idp essentially..
It would make little to no difference to end users but increase the security by default..
@ItalyPaleAle commented on GitHub (Nov 10, 2025):
Thanks for explaining, I now understand where you're coming from.
You're right that tokens saved in cookies could leak. However, I still think that if you're concerned with that, the best approach remains lowering the session duration for Pocket ID in the configuration.
I don't think that adding an extra check for a passkey would address the concern you're bringing up. Let's say we did add that, and users were prompted to re-verify their passkey when accessing the Pocket ID portal. To avoid asking them for the passkey on every page load, we'd need to save that successful check somewhere, like a cookie, and that is no different from the session cookie. IMHO cookies, especially HTTP-only ones served via TLS, are fairly safe and are widely used for security reasons. There is a risk that they are stolen, and for that the best protection is to make them short-lived, which in the case of Pocket ID means reducing the session duration.
That said, you are bringing up a specific scenario which I think could warrant some additional security: adding a passkey. If you're ok, we could reframe the issue specifically for the scenario of adding a passkey, enforcing that:
@James18232 commented on GitHub (Nov 10, 2025):
Not a problem.
My reasoning is that adding an initial authorisation check for pocket id (and having a short session duration) is more secure than relying on every session cookie issued when accessing every client on every device to remain secure - there is no legitimate need or reason i can think of that authenticating for access to a client should result in potential access to the users idp instance.
It also means you can be more generous with cookie timeframes for clients without impacting security (assuming you can change this in future).
I agree that http cookies over TLS are secure, and this is an edge case. Until there is support for adding isolated client authentication proposed in #939 this is a risk users have no meaningful way of mitigating other than very low session times (which are not able to be changed until there is support for #1056 as you mentioned earlier.
Most users will be authenticating to access clients most of the time, and this change would meaningfully reduce the risk profile - so i think it is worthwhile.
However, I also agree with you re the need to revalidate when adding a new passkey and alerting changes. Both should be adopted in my view. Unfortunately this was closed as not planned in #997 so yeah 🤷♂️.
@barryp commented on GitHub (Jan 16, 2026):
I think the current behavior is an issue when it comes to a user managing what web apps they're logged in-to/or out-of...
If I write say a Laravel app that uses OIDC to log in, that works pretty well, but essentially I've logged into 2 different sites at one time. When the time comes to log out, do I ...
Yeah, you could set a short session length in pocket-id, but again what if I explicitly want to be working in the pocket-id web UI ... I'd get kicked out every 5 or 10 minutes or whatever if I happened to look away and maybe not be continously working in that UI.
So basically, I feel like requiring reauthentication would be a good way to separate out using pocket-id as an authentication source for another webapp from using the pocket-id web ui itself.