Ball API Resource security with Asgardeo scope

[spice cedar]

To secure API resources in Ballerina, according to the doc, I can put scope like
so if in JWT scope is not listed resource can't be invoked

@http:ResourceConfig {
auth: [
{
jwtValidatorConfig: config,
scopes: ["br_smk_gnt"]
}
]
}
isolated resource function post brewery(...)
{. ...... }

So, related to story, Asgardio scopes are responsible to bring attributes from the user profile. When I create JWT in the request payload I can put any scope, with no limitation (based on my roles or permission) so I miss seeing how the scope brings extra security by restricting which user can call which resource ?!?

[exotic pier]

Adding @rough vector

[rough vector]

looping @willow peak

[willow peak]

@spice cedar as I understand Asgardeo generates the JWT based on the user roles and permissions. So, you can not generate a JWT with unauthorized scopes because Asgardeo being the identity-provider does not allows it. In the service level what happens is that the service validates the JWT by checking whether the required permissions are there (by validating scopes) and verifies the JWT signature to identify that this particular JWT is issued by Asgardeo itself. Both these functionalities combined it provides an enhanced security for an API.

[spice cedar]

@willow peak ".....Asgardeo generates the JWT based on the user roles and permissions...."
I cannot agree with this statement. As I see, Asgardeo doesn't have a link with the scope and user role. I would like you to convince me othervise and send me a document refernece.

[spice cedar]

IMO concept of scopes in Asgardio is, related to getting more info about user details rather that linking to security and user authorization. IMO there is misleading in the way that scopes are used in Ballerina as security declaration for API resources

[warped echo]

@spice cedar OIDC scopes and OAuth2 scopes have a different meaning. OIDC scopes as you have said stands for a collection of user attributes (claims). In contrast, OAuth2 scopes bind roles and permissions. In WSO2 IS, we can add such scopes (to represent permissions) and bind them to roles via a REST API. And then ask for that scope when requesting an access token. Have a look at https://gdrdabarera.medium.com/rbac-role-based-access-control-via-oauth2-0-scopes-with-wso2-identity-server-dd6dcb0b737b for more on this.

However, in above case, the idea is that the ballerina service can validate any claim in the received JWT for authorization purposes. By default name of the claim that is used to validate permissions is scope. You can configure a different claim by setting the name of the claim as scopeKey. The value of the selected claim should be either a string or a string[].