Scopes for Web api in Openid connect - asp.net-core

Question

I am using Identityserver4 for AuthZ and AuthN and trying to understand the purpose of scopes for a webapi
I am implementing a first party application an internal application which will works in intranet. so there will be no consent page.
image : application architecture
I have 3 users
User X : who can perform read and write operation on Web API ‘A’ Only
User Y : who can perform read and write operation on Web API ‘B’ Only
User Z : who can perform read and write operation on both Web API ‘A’ and ‘B’
Since all the user will log in using the ‘Angular front end’. In the front at the time of login the scopes requested must be like below
{
response: code
scopes : ‘openid A:read A:write B:read B:write’
}
As I said earlier, I am using Identityserver4 once the user successful logins the client will receive Id_token and access_token.
I understood from different article that api will check for the scope to provide access to an operation like read and write. So,
If User X logs in, access_token should contain scope only A:read, A:write
If User Y logs in, access_token should contain scope only B:read, B:write
If User Z logs in, access_token should contain scope only A:read, A:write, B:read, B:write
Since ‘Angular front UI’ is same for all the 3 users (X, Y, Z) in my case.
Client will request all the scopes (A:read, A:write, B:read, B:write) is this correct ?
Do I need to write any custom logic when access_token is getting generated, its should include only scope that user is entitled too?
If I have to write this custom logic which interface I need to implement. is it IProfileService?. i have to use something like role to find out the scopes?
Lastly, in other word, scopes for an web api is nothing but permissions am I right?

Answer 1

In IdentityServer I would create one ApiScope (perhaps named ApiAccess). Then I would create two ApiResources, one for each API and associate them with the ApiScope created earlier.
Then have a UserClaim (perhaps named access) associated with the ApiScope, that contains the particular users access (read or write).
the value for the access claim is then retrieved from the user database.
Also, do see my answer here for a clarification between ApiSope, ApiResources and IdentityResources.
To complement this answer, I write a blog post that goes into more detail about this topic:
IdentityServer – IdentityResource vs. ApiResource vs. ApiScope