🚀 Feature: isolated client authentication #33

New Issue

OVERLORD · 2025-10-06T23:58:52+03:00

OVERLORD commented

2025-10-06 23:58:52 +03:00

Originally created by @James18232 on GitHub.

Feature description

Feature Request to add an option to the create login code page and/or authentication prompt page when using the authorization code flow to use a ‘isolated login’. This login should not set any cookies on the device upon authentication by the user or include any refresh token to the client.

This could be achieved by a seperate button for the user to select when authenticating.

This is distinct from requiring reauthentication on each authorization per client, which is already supported.

Pitch

When logging into a client service on a ‘less trusted’ device you dont have full control of (eg shared public library computer, friend or family devices) - for example to show photos from an immich album - the user may forget to close a browser or have sign outs incorrectly implemented.

This may lead to unwanted/accidental access to other services and the pocket id instance itself via sso (assuming no requires reauthentication is set).

Having a ‘isolated authentication’ would not stop continued access to the intended service in this scenario, as I believe this is up to the client to invalidate/sign out, but it would prohibit access to any other services or the pocket id instance itself.

The user could use this isolated login in these instances to access a specific service only.

Originally created by @James18232 on GitHub. ### Feature description Feature Request to add an option to the create login code page and/or authentication prompt page when using the authorization code flow to use a ‘isolated login’. This login should not set any cookies on the device upon authentication by the user or include any refresh token to the client. This could be achieved by a seperate button for the user to select when authenticating. This is distinct from requiring reauthentication on each authorization per client, which is already supported. ### Pitch When logging into a client service on a ‘less trusted’ device you dont have full control of (eg shared public library computer, friend or family devices) - for example to show photos from an immich album - the user may forget to close a browser or have sign outs incorrectly implemented. This may lead to unwanted/accidental access to other services and the pocket id instance itself via sso (assuming no requires reauthentication is set). Having a ‘isolated authentication’ would not stop continued access to the intended service in this scenario, as I believe this is up to the client to invalidate/sign out, but it would prohibit access to any other services or the pocket id instance itself. The user could use this isolated login in these instances to access a specific service only.

OVERLORD added the needs more upvotes label 2025-10-06 23:58:52 +03:00

OVERLORD commented

2025-10-06 23:58:53 +03:00

@kleinweby commented on GitHub:

To suggest another naming for this feature: "Remember Me". Under the "Authenticate" Button there would be a "Remember Me" Checkbox, if checked (the default) the current behaviour is used. If unchecked the new behaviour described here is used.

@kleinweby commented on GitHub: To suggest another naming for this feature: "Remember Me". Under the "Authenticate" Button there would be a "Remember Me" Checkbox, if checked (the default) the current behaviour is used. If unchecked the new behaviour described here is used.

OVERLORD commented

2025-10-06 23:58:53 +03:00

@James18232 commented on GitHub:

Thanks. The feature is more akin to ‘incognito login’ to borrow from browsers. People probably get the concept with that name.

I would not start with adding to the current basic auth flow. Its simplicity remains a feature of its own.

I think to start an incognito button under the login code button in my account is the best way to go.

For most use cases you would be logging in from your own device anyway and get punted straight to this page, so its still a seamless code login. This incogntio code is just treated differently on the backend.

@James18232 commented on GitHub: Thanks. The feature is more akin to ‘incognito login’ to borrow from browsers. People probably get the concept with that name. I would not start with adding to the current basic auth flow. Its simplicity remains a feature of its own. I think to start an incognito button under the login code button in my account is the best way to go. For most use cases you would be logging in from your own device anyway and get punted straight to this page, so its still a seamless code login. This incogntio code is just treated differently on the backend.

OVERLORD commented

2025-10-06 23:58:54 +03:00

@kleinweby commented on GitHub:

(sorry for writing twice) Another use case would be to improve the use of different accounts. E.g. one account with admin rights which I just want to use for this one login to elevate my privileges. Otherwise I would use my "normal" account.

@kleinweby commented on GitHub: (sorry for writing twice) Another use case would be to improve the use of different accounts. E.g. one account with admin rights which I just want to use for this one login to elevate my privileges. Otherwise I would use my "normal" account.

OVERLORD commented

2025-10-06 23:58:54 +03:00

@kmendell commented on GitHub:

I personally wouldnt need to use this, but i added the needs more upvotes label. If the community wants this we can think about implementing it.

@kmendell commented on GitHub: I personally wouldnt need to use this, but i added the needs more upvotes label. If the community wants this we can think about implementing it.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id#33