Scoped Session Tokens

New Feature / Enhancement Checklist

• Report security issues confidentially.
• Any contribution is under this license.
• Before posting search existing issues.

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

• Always handing out regular session tokens (problematic from a security perspective, as then the API partner has more privileges than they actually need)
• Creating "phantom users" associated with the main user but limited in terms of the Parse roles they have access to, and handing out access token for these (difficult to audit the corresponding logs, business logic (eg. triggers) needs to be phantom-user-aware for certain uses cases).

3rd Party References

GitHub supports access scopes: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes

Start by tracing session-token handling and the ACL and CLP checks, then review how _Session and _Role data are used. Determine how a session’s scoped roles should interact with direct versus indirect roles, including cloud functions and triggers. Done means externally created scoped session tokens are respected while sessions without the relation retain existing behavior.