Let's come up with a standardized way to store auth

alexgleason commented

2020-06-19 15:21:21 +00:00

Corresponding Soapbox FE issue: https://gitlab.com/soapbox-pub/soapbox-fe/-/issues/148

With swappable frontends being a thing, and with at least 4 in active development, I think it would be ideal to make the process of switching frontends seamless for the users. As it stands, moving to a different frontend requires all users to log in again on the new frontend. This is inconvenient and could cause loss of traffic on larger servers.

I believe this is something all frontends will care about, since it's just as valid to switch from Soapbox FE into Pleroma FE, or between any other two frontends.

When I was coding the auth side of Soapbox FE, I made an attempt to mimic Pleroma FE's auth for compatibility, but ran into a few roadblocks:

It does not store OAuth expiration info or refresh tokens, making it seemingly impossible(?) for the frontend to handle Pleroma's auto-expire feature. In Soapbox FE I store the entire HTTP response from creating the tokens so we can deal with that.
It seems somewhat library specific. It's saved under a key called vuex-lz (is this Vue specific?) and seems to use the library localforage, which is another dependency I haven't used. In Soapbox FE I'm storing auth inside of native localStorage.

Pleroma FE auth

Soapbox FE auth

(Don't worry, these aren't live tokens)

The actual file where auth is handled in Soapbox FE can be found here: https://gitlab.com/soapbox-pub/soapbox-fe/-/blob/develop/app/soapbox/reducers/auth.js

It uses two keys in localStorage:

soapbox:auth:app
soapbox:auth:user

Anyway I just wanted to open an issue here to get started thinking about this problem. I don't have a proposal or anything, but I think it will probably be something we'll want to figure out.

If we decide we can't come up with a standardized way, then I'll probably be adding an Authmogrifier to Soapbox FE to handle all the auth from different frontends. 😄

Corresponding Soapbox FE issue: https://gitlab.com/soapbox-pub/soapbox-fe/-/issues/148 With swappable frontends being a thing, and with at least 4 in active development, I think it would be ideal to make the process of switching frontends seamless for the users. As it stands, moving to a different frontend requires all users to log in again on the new frontend. This is inconvenient and could cause loss of traffic on larger servers. I believe this is something all frontends will care about, since it's just as valid to switch from Soapbox FE into Pleroma FE, or between any other two frontends. When I was coding the auth side of Soapbox FE, I made an attempt to mimic Pleroma FE's auth for compatibility, but ran into a few roadblocks: 1. It does not store OAuth expiration info or refresh tokens, making it seemingly impossible(?) for the frontend to handle Pleroma's auto-expire feature. In Soapbox FE I store the entire HTTP response from creating the tokens so we can deal with that. 2. It seems somewhat library specific. It's saved under a key called `vuex-lz` (is this Vue specific?) and seems to use the library localforage, which is another dependency I haven't used. In Soapbox FE I'm storing auth inside of native localStorage. ## Pleroma FE auth ![Screenshot_from_2020-06-07_15-00-24](/attachments/5a5c6320-c6d3-4a36-9c3c-bdedd18a0c94) ## Soapbox FE auth ![Screenshot_from_2020-06-19_10-15-20](/attachments/1f86fbce-86d6-45d6-b098-9dc3c75b6857) (Don't worry, these aren't live tokens) The actual file where auth is handled in Soapbox FE can be found here: https://gitlab.com/soapbox-pub/soapbox-fe/-/blob/develop/app/soapbox/reducers/auth.js It uses two keys in localStorage: - `soapbox:auth:app` - `soapbox:auth:user` Anyway I just wanted to open an issue here to get started thinking about this problem. I don't have a proposal or anything, but I think it will probably be something we'll want to figure out. If we decide we can't come up with a standardized way, then I'll probably be adding an *Authmogrifier* to Soapbox FE to handle all the auth from different frontends. :smile:

Screenshot_from_2020-06-07_15-00-24.png

57 KiB

Screenshot_from_2020-06-19_10-15-20.png

55 KiB

alexgleason commented

2020-06-19 15:23:15 +00:00

Author

Oh shoot, I forgot to add that as a bonus it would be great if we could store it in a way that allows for multiple account support in the future, kinda like how Tusky lets you switch between logged in accounts.

shpuld commented

2020-06-19 15:32:59 +00:00

Owner

very good concerns, the names of the different stuff indeed comes from various libraries, perhaps auth should have its own javascript library that various frontends could share, which works directly with browser apis for storing it

hj commented

2020-06-19 15:34:56 +00:00

Owner

I really don't like the idea of sharing auth data between frontends. Does OAuth even support something like that? Will it reuse same token for all frontends? All of this give me "security vulnerability" vibe

shpuld commented

2020-06-19 15:36:17 +00:00

Owner

it only works on the same domain, so server admin basically allows for all frontend software they install to share the same data

no new vulns are introduced when different frontends can already ready the same localstorage/indexeddb

it only works on the same domain, so server admin basically allows for all frontend software they install to share the same data no new vulns are introduced when different frontends can already ready the same localstorage/indexeddb

alexgleason commented

2020-06-19 15:38:57 +00:00

Author

I think making a third-party lib is a great idea. Sort of like how pleroma-api is its own library.

hj commented

2020-06-19 15:43:21 +00:00

Owner

i mean yeah, sure, it's already a vulnerability, but this feels like making it even worse. Logging into different FE isn't a big deal

hj commented

2020-06-19 15:43:37 +00:00

Owner

which pleroma-fe isn't using lmao

alexgleason commented

2020-06-19 15:45:22 +00:00

Author

Neither is Soapbox FE, but I think an auth library would be much simpler.

shpuld commented

2020-06-19 16:38:10 +00:00

Owner

it's added convenience without losing out on anything

hj commented

2020-06-19 16:48:59 +00:00

Owner

auth is closely related to security, convenience features in security-related fields usually leads to reduced security. Sorry this is as constructive as I can possibly get.

alexgleason commented

2020-06-19 17:34:26 +00:00

Author

It does not lead to reduced security... is this really a valid concern? I sometimes feel like when I propose things people respond based on who I am instead of what I said. If @shpuld would have opened this exact same issue would there be any pushback?

Auth is already stored in the browser on a per-domain level. Browsers trust content on the same domain by design. If you think that's a security issue, then it's an issue with the browser itself.

Pleroma FE is free to handle auth however they want. This issue is an olive branch to create better interoperability, if you so choose.

It does not lead to reduced security... is this really a valid concern? I sometimes feel like when I propose things people respond based on who I am instead of what I said. If @shpuld would have opened this exact same issue would there be any pushback? Auth is already stored in the browser on a per-domain level. Browsers trust content on the same domain by design. If you think that's a security issue, then it's an issue with the browser itself. Pleroma FE is free to handle auth however they want. This issue is an olive branch to create better interoperability, if you so choose.

shpuld commented

2020-06-19 18:12:16 +00:00

Owner

I can guarantee it's not about you

hj commented

2020-06-19 18:38:36 +00:00

Owner

again, i don't entirely understand how it will work with oauth. Are you gonna just reuse same token/client secret? If so it would mean that other FE would NOT appear in OAuth token list and would be impossible to revoke permission to that without revoking PleromaFE token?

alexgleason commented

2020-06-19 19:44:17 +00:00

Author

Yes, exactly. The token would be reused.

It's true that within the "Revoke an OAuth token" GUI the app name would be potentially misleading if it was, for example, requested by Pleroma FE even though Soapbox FE is the one now using it, but I think this is a problem that can be solved.

I disagree that logging into a different FE is no big deal. Imagine a site with 10,000 idiots, including people who genuinely struggled to complete the registration form in the first place. These are the type of people I'm building Soapbox FE for. Maybe we're approaching this with a different design philosophy, but I've always followed the advice to "design for people who are very drunk," and then it becomes accessible to regular people.

At any rate, I'll update this again if I come up with any solutions.

Yes, exactly. The token would be reused. It's true that within the "Revoke an OAuth token" GUI the app name would be potentially misleading if it was, for example, requested by Pleroma FE even though Soapbox FE is the one now using it, but I think this is a problem that can be solved. I disagree that logging into a different FE is no big deal. Imagine a site with 10,000 idiots, including people who genuinely struggled to complete the *registration form* in the first place. These are the type of people I'm building Soapbox FE for. Maybe we're approaching this with a different design philosophy, but I've always followed the advice to "design for people who are very drunk," and then it becomes accessible to regular people. At any rate, I'll update this again if I come up with any solutions.

hj commented

2020-06-19 19:50:21 +00:00

Owner

so basically we want SSO, and we need something like SAML for it i guess?

lambadalambda commented

2020-06-20 10:30:52 +00:00

Owner

No, the idea is much simpler, it's about sharing the access token when run on the same domain. That is, a server uses PleromaFE. Then the admin decides to switch the default frontend to soapbox. Currently, this will mean that every user has to log in again, even though the access token is still there in local storage. Now soapbox could just go and pull it out from the place in localstorage/indexeddb where it is right now, but this isn't a standard (although it will probably never change without reason), so it's a bit of a hack.

The idea here (at least that's what I think) is that we just say "when you write a pleroma frontend, put your oauth data (access token, app token, etc) into local storage at these specific keys, because when you do you won't have to log in again after switching frontends".

No, the idea is much simpler, it's about sharing the access token when run on the same domain. That is, a server uses PleromaFE. Then the admin decides to switch the default frontend to soapbox. Currently, this will mean that every user has to log in again, even though the access token is still there in local storage. Now soapbox could just go and pull it out from the place in localstorage/indexeddb where it is right now, but this isn't a standard (although it will probably never change without reason), so it's a bit of a hack. The idea here (at least that's what I think) is that we just say "when you write a pleroma frontend, put your oauth data (access token, app token, etc) into local storage at these specific keys, because when you do you won't have to log in again after switching frontends".

hj commented

2020-06-20 13:15:25 +00:00

Owner

if admin switches default frontend it's already kind of a dick move to begin with, in that regard we need to implement more than just auth token sharing - we need a cookie to remember default FE so that if admin changes default frontend users won't see the change if they prefer using previous default one.

hj commented

2020-06-20 13:18:03 +00:00

Owner

otherwise it means more than "put oauth date in specific place", it also means "make sure to register your app with specific name so that it doesn't look confusing in token revoke list" and maybe even more details.

lambadalambda commented

2020-06-21 11:36:55 +00:00

Owner

Admins can do do already switch frontends without any way for the user to override it beyond running their own. We don't need to enforce instance policies.

hj commented

2020-06-21 13:35:03 +00:00

Owner

if admin initially set different frontend - there's no problem of "having to log in again", if admin set different frontend somewhere in the middle of the life of an instance that as I said a dick move and i wouldn't want to support nor endorse that. Even then it's a one-time issue of log-in-again, don't tell me admins are going to switch frontends every day, especially given that they have "10000 idiots who genuinely struggled to complete the registration form"

if admin initially set different frontend - there's no problem of "having to log in again", if admin set different frontend somewhere in the middle of the life of an instance that as I said a dick move and i wouldn't want to support nor endorse that. Even then it's a one-time issue of log-in-again, don't tell me admins are going to switch frontends every day, especially given that they have *"10000 idiots who genuinely struggled to complete the registration form"*

alexgleason commented

2020-06-22 22:14:12 +00:00

Author

I discovered that AdminFE already does this when you click the admin button at the top of Pleroma FE.

It reuses Pleroma FE's auth credentials here: https://git.pleroma.social/pleroma/admin-fe/-/blob/develop/src/services/pleromaAuth.js

I suppose localforage is still a requirement, but this seems like a good starting point.

I discovered that AdminFE already does this when you click the admin button at the top of Pleroma FE. It reuses Pleroma FE's auth credentials here: https://git.pleroma.social/pleroma/admin-fe/-/blob/develop/src/services/pleromaAuth.js I suppose localforage is still a requirement, but this seems like a good starting point.

alexgleason commented

2020-06-25 03:45:52 +00:00

Author

So I've been thinking about this thing lately:

I'd like to add some features to it, especially to bring it closer to what Mastodon offers:

It occurred to me that Mastodon knows who you are already. It uses a cookie. Pleroma makes you enter a password every time, even if you're already logged into Pleroma FE.

I wonder if maybe a cookie set by Pleroma can be used to also give you auth on the frontend? Maybe the cookie could be set by logging into any frontend, then it can be used to generate a new user token somehow. My first instinct is to let you POST /oauth/token with grant_type: "cookie"

(I'll probably send some MRs related to the OAuth form in the future.)

So I've been thinking about this thing lately: ![Screenshot_from_2020-06-24_22-38-10](/attachments/ea43c847-d102-4d8b-b9f6-c721f1d2c215) I'd like to add some features to it, especially to bring it closer to what Mastodon offers: ![Screenshot_from_2020-06-24_22-40-32](/attachments/da17fe6a-af81-46c0-986c-cf35611556ad) It occurred to me that Mastodon knows who you are already. It uses a cookie. Pleroma makes you enter a password every time, even if you're already logged into Pleroma FE. I wonder if maybe a cookie set by Pleroma can be used to also give you auth on the frontend? Maybe the cookie could be set by logging into any frontend, then it can be used to generate a new user token somehow. My first instinct is to let you POST `/oauth/token` with `grant_type: "cookie"` (I'll probably send some MRs related to the OAuth form in the future.)

Screenshot_from_2020-06-24_22-38-10.png

21 KiB

Screenshot_from_2020-06-24_22-40-32.png

32 KiB

hj commented

2020-06-25 08:16:05 +00:00

Owner

IIRC mastodon doesn't exactly support installing multiple or even just different FEs, so essentially different "frontends" or rather parts of mastodon all are essentially MastoFE.

However the idea of having a cookie BE sets that's NOT tied to some FE Oauth token/secret seems decent enough to me. "Authorize another application" sounds much better than "reuse existing stuff"

IIRC mastodon doesn't exactly support installing multiple or even just different FEs, so essentially different "frontends" or rather parts of mastodon all are essentially MastoFE. However the idea of having a cookie BE sets that's NOT tied to some FE Oauth token/secret seems decent enough to me. "Authorize another application" sounds much better than "reuse existing stuff"

seanking added the

Feature Request / Enhancement

label

2026-02-20 03:24:34 +00:00

Rows
Columns

Let's come up with a standardized way to store auth #871

Pleroma FE auth

Soapbox FE auth