· 2 min read
Defining Scopes for your OAuth Service
Placeholder
Here’s my thinking on how we should design scopes for OAuth. And how many a proper REST API could simplify the process.
In a rest API, we have resources. Our resources are usually accessed with just a noun.
so,
GET
/movies
to get all movies
GET
/movies/{movieId}
to get a specific movie
PUT
/movies
to modify a movie
POST
/movies
to add a new movie
DELETE
/movies/{movieID}
to delete a movie
Our Outh scopes are a restriction on resources
so, we would have scopes for movies
resource.
We can append this with the kind of method that can be run on the resource.
For example:
read:movies
-> allows GET
calls on /movies
REST API resource
write:movies
→ allows POST
calls on the /movies
resource.
read:userinfo
→ allows GET
calls on the /userinfo
resource
When the app is submitted to our “App Store“, the app developer declares an app, they are using a particular scope.
For example, let’s say an App that shows user recommendations has asked for read:movies
, write:movies and
read:userinfo
.
The app developer has declared why they use each of the scopes. While declaring, they decide they aren’t using the write:movies
scope.
So, they remove it. Or while reviewing the app submission application, the App Store platform rejects the request for accepting write:movies
and asks for more clarifications.