What use are 'Scopes' in Azure B2C Authentication?

后端 未结 2 665
慢半拍i
慢半拍i 2021-02-14 16:37

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 pra

2条回答
  •  遥遥无期
    2021-02-14 16:44

    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.

提交回复
热议问题