In my Auth0 use case I have users & projects (many-to-many relationship). The projects a user has access to are stored in app_metadata. On the API side I need one token (I suppose access_token type) for every project a user has access to, such that the project is in the scope of the token. It is a requirement to have one token per project because the backend cannot be fully trusted not to steal tokens which give access to other projects.
Are access_tokens the right tool for this authorization use case and if they are, is there a limit to the number of different scopes I can create for a given API? (so every time a new project is created I will create a new scope in the API for it).
In general, scopes are not that fine-grained, more specifically, it would be more common to have scopes like read:projects, create:projects, etc rather than have scopes likes project:001 and project:002 that are associated to a single entity.
The reason for the more generic scopes approach is that having per-entity scopes may not scale in most situations due to the number of entities involved.
Access tokens are indeed the correct type of token to use for the scenario where an application calls an API on behalf of an end-user, however, in relation to the granularity of the scopes the general recommendation would probably tend to the usage of more general scopes. Having said that, you mention a requirement that is curious, the fact that the backend should receive a token that only allows access to a single project. I’m assuming this backend represents the client application, but if the user has access to several projects what would stop the client application to request multiple individual tokens for each project? In conclusion, you seem to have a very specific scenario where a definitive answer would likely require knowing all the little details.
The use case is the following: user A may have access to project 1 and project 2. User B may have access only to project 1. When a user has access to a project they can intercept the tokens received by the backend for that project (because they have control over the backend/subdomain). If User B is a malicious user then he can modify the backend for project 1 and steal the token of User A thus gaining access to project 2. The backend needs to authorize every request that’s why I was hoping to use tokens as a high performance solution.
And the backend Is not the client application. It’s an API, or Resource Server in OAuth terms.
In general an OAuth2 resource server is the part that can be trusted, it requires an access token as means to ensure that the calling client application is authorized to do such a call. If you’re treating your back-end as a resource server, but you don’t trust it, the situation is a bit complex to look at from the perspective of OAuth2.
In general an OAuth2 resource server is the part that can be trusted, it requires an access token as means to ensure that the calling client application is authorized to do such a call. If you’re treating your back-end as a resource server, but you don’t trust it, the situation is a bit complex to look at from the perspective of OAuth2.