When scope is disabled or deleted, Obo flow can still get access token

[moarychan]

For the existing scope, two circumstances:

• after disabling the scope
• after deleting the scope

I expect the error can be returned immediately when I disable or delete a certain scope, instead of continuing to return available tokens.

[sangonzal]

@moarychan What do you mean by "scope is disabled or deleted"?

[moarychan]

Hi @sangonzal , I have a web application as a resource server, then I want to disable a certain scope to deny access to the resources, AAD should protect my resources in real-time according to the current scope definition.

[sangonzal]

@moarychan After you disable the scope, you are still able to acquire tokens for that scope?

After you disable or delete the scope, and acquire a new token, can you decode the access token (you can use a site like jwt.io) and share the value of 'scp' claim?

[moarychan]

Hi @sangonzal , thank you for your feedback, I hope to explain in detail:

• The simple case is that will access the resource directly, when I disable the scope, I can still acquire a new token that contains the same scope.

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjVPZjlQNUY5Z0NDd0NtRjJCT0hIeEREUS1EayIsImtpZCI6IjVPZjlQNUY5Z0NDd0NtRjJCT0hIeEREUS1EayJ9.eyJhdWQiOiJhcGk6Ly9jdXN0b20tY2xpZW50LWlkIiwiaXNzIjoiaHR0cHM6Ly9zdHMud2luZG93cy5uZXQvMWQxYTA2YTktYjIwYS00NTEzLThhNjQtZGFiMDhkMzJjOGI2LyIsImlhdCI6MTYwOTM4MjY4NSwibmJmIjoxNjA5MzgyNjg1LCJleHAiOjE2MDkzODYzOTQsImFjciI6IjEiLCJhaW8iOiJBU1FBMi84U0FBQUFST1VGNm4vOWdvbTlJRkhpY243VTBzTEVuZ3RPZlAxQjh1UGxUOTF5ZDJRPSIsImFtciI6WyJwd2QiXSwiYXBwaWQiOiIwZWUyYTg0ZS1iMjU1LTQxOGYtOTNiNi1lMmY1ZmU4NTBmODQiLCJhcHBpZGFjciI6IjEiLCJmYW1pbHlfbmFtZSI6ImNoZW4iLCJnaXZlbl9uYW1lIjoiYW15IiwiaXBhZGRyIjoiMTY3LjIyMC4yNTUuNzMiLCJuYW1lIjoiYW15IGNoZW4iLCJvaWQiOiJhYmQyOGRlMS05YzM3LTQ4OWQtOGVlYy1mZWVlZjRkMjc0YTMiLCJyaCI6IjAuQUFBQXFRWWFIUXF5RTBXS1pOcXdqVExJdGs2bzRnNVZzbzlCazdiaTlmNkZENFI0QUFJLiIsInNjcCI6IkZpbGUucmVhZCIsInN1YiI6InVnR0NDeGN2Z1JaM01aSmthQXNoWkhsNTlaSjY4WEJSMnZ5b2hEbjE5Y2ciLCJ0aWQiOiIxZDFhMDZhOS1iMjBhLTQ1MTMtOGE2NC1kYWIwOGQzMmM4YjYiLCJ1bmlxdWVfbmFtZSI6ImFteUBtb2FyeS5vbm1pY3Jvc29mdC5jb20iLCJ1cG4iOiJhbXlAbW9hcnkub25taWNyb3NvZnQuY29tIiwidXRpIjoiS2gyb3U4SmVBMDZFMzNEbXFVNWJBQSIsInZlciI6IjEuMCJ9.WjqVNemeaghNhRWVHWMoLto5RNDp6ayPxXZKK3mqprXC5jkyiVJayfzIhkDAYd-5JKGWwlj0FMYubb17rm9eKVTS1gYF59RMEJ4WlSojmGfn5WeEBePFW-uM3gS1qtSliXTVeqjYcPCs92D3ZuxjMlnIU4xTSwu_NVlnRoNzyqyvk1FgG3WB1VyWF7F5L_I5v8Ml6S5v8f27o1ulML-lU4ve41rbCSsvreW781mTW14Dq5wJsKWzIqUEWu6ovSSp35OMDNvPnlJwLzFpVLgiaiZhEeNjHPcmDZa4JaTUsYjQoYy-n7515Y_Fx8LBQ8dOwNXFRkoUCCGIYlN45zv1DA

If I use the same usage with the below case 2, the access token will also be returned successfully.

• Complex case
  There are 2 resource server applications protected by AAD, one is res1, another one is res2, res1 will depend on res2. Normally res1 can access res2 successfully when the exposed api of res2 are added to the api permission of res1.

But when I disable or delete the exposed api of res2(scope), the Obo flow to acquire the access token of res2 still works.

In both cases, the same problem is the access token should not be returned successfully.

[sangonzal]

@moarychan I was able to reproduce this behavior on my end. I have reached out to the team that owns the "Expose an API" blade in the portal and I'm waiting to hear back.

[harryvu]

I am having the exact same issue today - Oct 22, 2021. Does anyone explain or have a solution for it? Thanks.

[bgavrilMS]

MSAL uses token caching, the token will be sent for a while from the cache. The correct solution here is to forbid users in the organization from getting access token to the downstream api.