Hi Bharath,

You decide the scopes yourself as an implementor of that account API, and a
server for the account and org info resources it returns.

We've been having a related discussion of scopes with Piotr [1], where he'd
like the client to decide the scopes and I'm saying that the resource owner
and server should decide them instead. Well, here you're on the resource
server side so you get to decide :)

Quoting the OAuth spec for a bit more background [2]:
---
Tokens represent specific scopes and durations of access, granted by the
resource owner, and enforced by the resource server and authorization server
---

In terms of end to end flow, your account service is called by the Abacus
reporting service to retrieve the account and org info needed to generate
usage reports, and is passed the same token passed in to the reporting
service by the client requesting a report. So you need to have that client
pass a token with an identity and scopes that you can check in your account
service to protect the account and org info that you'll serve.

You can decide how you want to implement this, but if the client presents a
user token for example, you could check for some scopes in that token but
you may also want to check the roles assigned to that user in the requested
org to control whether or not she's allowed to access the org info.

HTH

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Re-abacus-Usage-submission-authorization-tt2115.html#none
[2] https://tools.ietf.org/html/rfc6749#section-1.4

- Jean-Sebastien

- Jean-Sebastien