19

I don't understand how the 'Scopes' in Azure B2C are supposed to be used. They are associated with an API, but not a user. I'm sure I'm missing something, but I see no practical use for something associated with an API. I've used and implemented Claims-based authentication based on a user's role in the database.

For example: ordinary users of an API should not have the authority to delete an object, but administrators should have the authority. Does someone have a practical example of how these B2C 'Scopes' can be used to limit a users access to the API?

spottedmahn
  • 14,823
  • 13
  • 108
  • 178
Quark Soup
  • 4,272
  • 3
  • 42
  • 74

2 Answers2

20

They are associated with an API, but not a user.

That is correct. I like to think of the association to the API as defining the 'surface area' of the API. For example, this API defines 2 scopes

  • read
  • write

Now, you could define two applications. One application that only has read permissions and one that has read and write permissions.

For the common use case of one Web App and one Web API it adds no value. I've been using a scope of no-op for such cases.

I've used and implemented Claims-based authentication based on a user's role in the database

You can use custom attributes to assign "role(s)" to the user. You can set them via the Azure AD Graph API to keep the setting of them secure. You can also set them during sign-up (this is much more involved though).

When you request an access token for that user, the custom attirbute(s) you defined and set will be readable in the API to check permission(s).

Comment Feedback

If I promote or demote a user, I need to change the endpoints (policies) they access at the client.

No need to change the policies. You would update the custom attribute for that user via the Azure AD Graph API.

My problem is that I'm mystified at the an authentication system that authorizes endpoints ("scopes") instead of users

Yeah, me too! I think it might have to do w/ the purpose of the product. B2C is about self-service sign-up, password reset and federating w/ other IDPs (like FB, Google, etc). Maybe Azure AD is a better solution when you want to control permissions on a user. Not sure, still learning!

I still don't see the practicality of splitting your API into several different parts based on the security. An API should be a collection of functionally related services

You don't split your API. You can split your app(s) that utilize the API. See above.

Documentation Reference: Requesting access tokens, GitHub Issue to improve the documentation.

spottedmahn
  • 14,823
  • 13
  • 108
  • 178
  • Thanks for the info, but it doesn't clear the matter up. How do you use this in a practical scenario? If I promote or demote a user, I need to change the endpoints (policies) they access at the client. How is that useful/practical? – Quark Soup Apr 17 '18 at 12:49
  • I understand how the custom attributes for a user work, but using the Graph API has a huge amount of overhead. My problem is that I'm mystified at the an authentication system that authorizes endpoints ("scopes") instead of users. I still don't see the practicality of splitting your API into several different parts based on the security. An API should be a collection of functionally related services. Breaking them up by security seems impractical and artificial. – Quark Soup Apr 17 '18 at 13:09
  • I agree - did you ever get anywhere with this? I have the same problem. – user2294382 Apr 02 '20 at 13:08
  • @user2294382 nope – spottedmahn Apr 02 '20 at 23:42
  • 1
    Thanks, this really cleared up the question of "why do I need to use scopes?" for me. The comparison to either creating multiple apps or just simply using a read/write scope instead was the Aha! moment as that was what I was struggling with understanding. – Architekt May 25 '21 at 14:19
  • I don't particularly understand how dividing scopes between multiple client increases security. It just pushes the problem forward. Assuming both apps use B2C as identity/access manager, a user who can sign in to the 'read' client app, can de-facto also sign in to the 'write' client app. With SSO, they don't even have to physically sign in. How do the client apps distinguish who gets to sign in and who doesn't? – Krishna Moniz Sep 16 '22 at 19:59
12

Roles and scopes provide the two halves for this user access control.

Roles -- such as Administrator, Member, and Guest -- determine whether an authenticated user is permitted to delete objects.

Scopes -- such as read, write, and delete -- determine whether an authorized application can delete objects on behalf of an authorizing/consenting user if this user, through their role assignment/s, is permitted to do so.

Azure AD B2C doesn't have any current support for managing roles and assignments of them to users.

It does, however, have support for managing scopes and assignments of them to applications.

Chris Padgett
  • 14,186
  • 1
  • 15
  • 28
  • This really doesn't answer the question, it just describes the problem. I want some users to have 'delete' access, I don't want other users to have 'delete' access to the exact same method on the exact same API. How do these policies help me accomplish this? – Quark Soup Apr 17 '18 at 12:54
  • Acknowledged @MikeDoonsebury I've updated the above answer to clarify this more. – Chris Padgett Apr 18 '18 at 09:07