Cannot understand the AllowedScopes options

[andreuwz]

Hello.

I have the following access token, which includes scopes (), issued by Identity Server 4, like this:
"scope": [ "Cart.API", "Catalogue.API", "Identity.API", "offline_access" ]
Also, in my ocelot configuration, for certain re-routings I have the following configuration:
"AllowedScopes": [ "Cart.API", "Catalogue.API", "Identity.API", "offline_access" ]

I want to ask, are the scopes created by IS4 the ones Ocelot looks for?
Because I tested the scopes in the token against 2 examples:
"AllowedScopes": [ "Cart.API", "Catalogue.API", "Identity.API", "offline_access", "test" ]
"AllowedScopes": [ "test" ]
In the first example where test is included in the list of scopes, using the token from above - I get forbidden. If I use only "test" scope I get Unauthorized. Is this expected behavior?

[ggnaegi]

@andreuwz As far as I understand it, the second example is giving you the expected result, since the test scope isn't included in the token's scopes.
https://github.com/ThreeMammals/Ocelot/blob/develop/src/Ocelot/Authorization/ScopesAuthorizer.cs

 if (!matchesScopes.Any())
            {
                return new ErrorResponse<bool>(
                    new ScopeNotAuthorizedError($"no one user scope: '{string.Join(',', userScopes)}' match with some allowed scope: '{string.Join(',', routeAllowedScopes)}'"));
            }

as for the first example, the error must be somewhere else, since you have some matching scopes (by the way it's an interesting debate: #231)

[raman-m]

Interestingly, a similar question by an author was raised in PR #1520, which was closed, yet the documentation was updated here:

Ocelot/docs/features/authentication.rst

Line 192 in ce0227c

If you add scopes to **AllowedScopes**, Ocelot will get all the user claims (from the token) of the type scope and make sure that the user has at least one of the scopes in the list.

This has led to an inconsistency due to the terms "all" and "at least." The underlying issue in the user scenario involves matching scopes by the IScopesAuthorizer service, as seen in issue #2177

• AllowedScopes feature is not functioning as anticipated during authentication with the OpenIddict server #2177

Consequently, I have assigned high priority to this issue and linked it to PR #1431.
Also, seems we need to extend AllowedScopes options proposing a setting for matching strategy.

[raman-m]

@andreuwz

I want to ask, are the scopes created by IS4 the ones Ocelot looks for?
Because I tested the scopes in the token against 2 examples:
"AllowedScopes": [ "Cart.API", "Catalogue.API", "Identity.API", "offline_access", "test" ]
"AllowedScopes": [ "test" ]
In the first example where test is included in the list of scopes, using the token from above - I get forbidden. If I use only "test" scope I get Unauthorized. Is this expected behavior?

Andrey, allow me to clarify the "forbidden issue" in the first case. The issue stems from the IScopesAuthorizer implementation, which is utilized during the authentication phase in Ocelot. More details about the root cause can be found in issue #2177.

Ultimately, it appears that the "AllowedScopes" feature may not function correctly due to the character-separated scope claim within the token. Therefore, in the first scenario, writing multiple roles/scopes has no impact due to bug #2177 (lack of complete logic). It seems the scope claim value is either Cart.API Catalogue.API Identity.API offline_access test or comma-separated, with the order being irrelevant.

In the second case, an unauthorized status indicates that the roles derived from the scope claim were not correctly parsed into the list. The claim value role1 role2 test was parsed as a single role role1 role2 test, whereas the ClaimsAuthorizer fails to find the test role during the second authorization stage in AuthorizationMiddleware, even though the first authentication stage was successful.

So, all these issues will be addressed in

• AllowedScopes feature is not functioning as anticipated during authentication with the OpenIddict server #2177
• #1739 #2177 OpenIddict authentication: role section, override scope and role key #1431