Open mstniy opened 3 months ago
Is this something that should be built into Parse Server, or something that could / should be custom-developed, because the specifics can vary depending on use case?
We already have CLP with user scope, which allows to customize access scope on a per-user basis. So any session token associated with that user should be scoped as well. If the current scoping is not enough, what exactly are you trying to scope?
The advantage of building this into Parse Server is twofold:
1) Our API consumers just interact with Parse, as opposed to a custom endpoint. They benefit from the SDKs, documentation and can use the REST and graphql APIs to their liking 2) We don't need to develop and maintain security-critical authorization logic as part of our code.
In this use case, per-user access is not enough, as the request is about scoping session tokens themselves. This means different session tokens for the same user should be able to have different levels of privilege.
This means different session tokens for the same user should be able to have different levels of privilege.
Got it. It doesn't sound like a simple thing to complement, and affects multiple repos. Let's keep this up for discussion.
New Feature / Enhancement Checklist
Current Limitation
Currently session tokens are not scoped. This is limiting for my team as we want to distribute Parse session tokens to our API partners, but restrict their access scope beyond that the corresponding user is capable of. This is a widely used practice for identity providers but unfortunately, to the best of our knowledge, is not supported by Parse.
Feature / Enhancement Description
We propose a relation field on the
_Role
collection be added to the_Session
collection. For backwards compatibility, if this field does not exist in the session object, the corresponding session token has the same set of roles as the user itself. If it does exist, it describes the set of Parse roles the corresponding session token can have direct access to, a subset of the Parse roles the corresponding user has direct access to. Note that indirect roles are not affected.ACL and CLP checks need to respect the scopes. Cloud functions/triggers could be given access to this restricted set of roles as well.
We are not planning to create scoped session tokens with Parse. Such session tokens will be created by an external OAuth adapter, but we want Parse to respect them.
Example Use Case
Providing an API partner with only read access, or access only to a specific collection/subset of objects.
Alternatives / Workarounds
3rd Party References
GitHub supports access scopes: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes