Open stefandesu opened 3 years ago
This also applies to Wikidata, doesn't it? For the user I'd avoid the word "token" but differentiate between simple login (just check your identity) and granting login server application editing rights.
Yes, it also applies to Wikidata, and yeah, that makes sense. I'm not sure about the application flow though. Also we'd need to have a way for the user to grant editing rights even after connecting the account.
When I added the easydb strategy, I wasn't sure about saving the access token for the user since, at this point, we don't need it. However, since we are planning integrations for the future where it will be needed, we decided to save it.
I was wondering whether it would make sense to give the user the option whether to save the token or not. That way, when the user only wants to use the easydb login for authentication, they can be sure that no application will be able to access that easydb instance under their account. This is especially important since easydb does not use the typical OAuth system where the access token only works in combination with an application token, meaning that anyone getting access to the token will have access to easydb under the user's account.
What do you think, @nichtich? Implementation would be fairly trivial, but we might have to add an option to the provider config to indicate whether, for a certain provider, there will be tokens involved or not.