read only token

[nzasch]

Hi! in a private instance of selfoss it would be nice to have a way to view feeds without exposing the login credentials, for example in a bookmarked url. I think that a configurable GET token can be a good way to do this.

many thanks!

[jtojnar]

Could you describe in more detail what is your use case?

For example:

• I do not want to enter the credentials all the time, selfoss should just work immediately after opening the page.

or

• I want to share my feeds with someone but do not want to make them public for everyone to see.

[nzasch]

hi my concern is to not store (and use/expose) credentials on read (for example on a mobile device). it's ok to have to login when adding sources and making changes.

The second example can be an extension of the first. If it is possible to store multiple read-only credentials then one can show his feed to friends!

thanks

[jtojnar]

I still do not understand what your threat model is. The web frontend only uses the credentials for the initial authentication, subsequent requests use a temporary session cookie. Now, we might add a more standard auth method to the public API but session cookie already works.

The two examples are quite distinct in my mind. In the first one, the request was driven by personal convenience – it would be basically a “Remember me” feature and using longer-term tokens than session cookie would be necessary. In the second one, the key would be shared around and also passed from the app URL to the API, requiring a more strict management.

[nzasch]

Thank you for your reply and patience :) My threat model is to leave write credentials (user/pass or session cookie) in a possibly insecure device (mobile, iot) I use daily to read feeds. You can view it as a disposable (and revocable) read-only credential.

If one can manage many such credentials, and they can be passed inside the URL, then he can pass them to friends. I am not directly interested in this second scenario, although I think it will be a nice feature.

[funwhilelost]

@jtojnar The common model I've seen for this is a user is able to create any number of bearer tokens, which they can revoke at any time. Then you could have a mobile client use a bearer token to retrieve the feed without exposing the full read-write credential set.

• If the mobile phone is compromised then the bearer token can be revoked
• The bearer token can also be given a smaller set of permissions (read-only, usually)