A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Specific suggestions appreciated! Here is admin doc related section and more info on scopes. Here is github issue.
https://oauth.net/articles/authentication/
That aside, why is nextcloud asking for scopes from remote API in the diagram? What is drawn on the diagram has little to do with OAuth scopes, but rather looks like an attempt to wrap ACL repository access into a new vocabulary.
Scopes issued by the OAuth authorization server can be hidden entirely. The issuer doesn’t hold any obligation to share them with authorized party since they are dedicated for internal use and can be propagated via invisible or opaque means.
I really can’t figure out what’s going on with that diagram.
The email address scope is commonly used as a shared identifyer for linking accounts.
Thanks, this helped me better understand what is going on. Tried to formulate a response: https://github.com/nextcloud/server/issues/26233#issuecomment-3217564155
I’d probably add that for something like nextcloud granted scopes can be an „orthogonal”–for the lack of a better word–subset of requested scopes.
The set of requestable scopes has to be defined by the system itself, not its specific configuration. E.g. „files:manage”, „talk:manage”, „mail:read” are all general capabilities the system offers.
However, as a user I can have a local configuration that adds granularity to the grants I issue. E.g.: „files:manage in specific folders” or „mail:read for specific domains or groups only” are user trust statements that fit into the capability matrix but add an additional and preferably invisible layer of access control.
It’s a fairly rare feature in the wild and is a potential UX pitfall, but it can be useful as an advanced option on the grant page, or as a separate access control for issued grants.
Thank you for answering this person, it amazes me how little people know of oauth, and it’s not a new tech.