locked
Identity Server 3 - OAuth 2 the same scope for different Resources RRS feed

  • Question

  • User-781712322 posted

    Hi,

    Let me start with the sentence that I am new in the OAuth world. Recently, I read all the standards regarding OAuth, OpenID Connect, HOSE etc.

    That I come to the some scenario that I just can not find how to cover with OAuth, probably because OAuth is hard to digest at the beginning. :-)

    So, let we say that we have:

    1. Two services that I want to protect Resource A (Service A, some WebAPI service) and Resource B (Service B, some WebAPI service), and we have Identity Server 3 (the implementation of OpenID Connect (including OAuth 2.0). 

    2. Resource A have the following scopes: scope_a, scope_b ,  Resource B have the following scopes: scope_a, scope_c

    But here scope_a in Resource A and Resource B are really do not mean the same thing.

    Those two services are part of the larger system. And some user should have access to those services but with different privileges.

    So when OAuth dance is done the client gets an AccessToken and the client can pass this token to both Service A and Service B

    So how to differentiate between those two scopes scope_a (Service A) and scope_a (Service B)?

    When those scopes are included in the token, and the token is passed to the Resource, how the Resource know if this token is actually issued for that Resource or some other?

    Sunday, September 27, 2015 1:29 PM

Answers

  • User-219423983 posted

    Hi iAuth,

    So how to differentiate between those two scopes scope_a (Service A) and scope_a (Service B)?

    When those scopes are included in the token

    Scopes let you specify exactly what type of access you need. Scopes limit access for OAuth tokens. They do not grant any additional permission beyond that which the user already has. The strings are defined by the authorization server. So, you don’t need to consider about how to differentiate between those two scopes, this makes no sense.

    And when the token is passed to the Resource,

    It is passed to the resource together with the token.

    how the Resource know if this token is actually issued for that Resource or some other?

    It use the Client Identifier to differentiate where the request comes from and the then generate the corresponding token.

    For more things, you could take a look at the following link which is the github oauth introduction that you could have a look.

    https://developer.github.com/v3/oauth/

    I hope it’s useful to you.

    Best Regards,

    Weibo Zhang

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, September 28, 2015 5:43 AM

All replies

  • User-219423983 posted

    Hi iAuth,

    So how to differentiate between those two scopes scope_a (Service A) and scope_a (Service B)?

    When those scopes are included in the token

    Scopes let you specify exactly what type of access you need. Scopes limit access for OAuth tokens. They do not grant any additional permission beyond that which the user already has. The strings are defined by the authorization server. So, you don’t need to consider about how to differentiate between those two scopes, this makes no sense.

    And when the token is passed to the Resource,

    It is passed to the resource together with the token.

    how the Resource know if this token is actually issued for that Resource or some other?

    It use the Client Identifier to differentiate where the request comes from and the then generate the corresponding token.

    For more things, you could take a look at the following link which is the github oauth introduction that you could have a look.

    https://developer.github.com/v3/oauth/

    I hope it’s useful to you.

    Best Regards,

    Weibo Zhang

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, September 28, 2015 5:43 AM
  • User-781712322 posted

    Hi Zhang,

    thank you for answer but this is still not clear to me.

    As I mentioned I read all the standards, so the idea of scope is familiar to me, at least I think it is.

    Let we make practical example. If we have two WEB API services that we want to protect with OAuth.

    What is the best practice to map scopes to Web API methods of controllers?

    Do I relate scope to specific method of WEB API controller or the complete service?

    How claims (the one related to roles) fits to this?

    Monday, September 28, 2015 9:20 AM