On 2/06/2015 04:26, Christopher Karlof wrote: > A scope, which is just a string, like “profile”, is a permission that is > associated with a token. A token with a “profile” scope means that token > has the permission to read and write the user’s profile. The > authentication flow would for using such a token would be something like: > > 1) A client sends a request to the FxA Profile API, including the OAuth > token as a bearer token. > 2) The Profile server extracts the token, verifies it [1], and gets the > lists of scopes associated with it. > 3) The Profile server verifies that “profile” is on the list of scopes, > which is the scope associated with the FxA Profile API. If the “profile" > scope is missing, that means this token does not have the appropriate > permission to use the FxA Profile API, and the request should be rejected. > > If you want to use FxA OAuth to authenticate your API, we need to agree > on a scope that represents your API, e.g., “mozstumbler”. Then, in the > login flow for your app you would request the scopes “mozstumbler > profile” [2]. This means when the login completes, your application > would obtain a token for the user with permission to use your backend > API (i.e., “mozstumbler”) and permission to use the profile API for that > user (i.e., “profile”). This token can now safely be used from the > mobile app (i.e., to use the mozstumbler) or from the backend. > > A trusted relier (which I think MozStumbler would be) can currently > request any scope it wants (I believe this is still the case), even if > it doesn’t exist yet. Longer term we should probably lock this down a > bit, to improve error messaging at the least.
(Adding my 2c to the explanation in the hope that it's helpful...) The tricky thing with understanding scopes is that there are two distinct types of application in an OAuth ecosystem: Relying Parties and Service Providers. A Relying Party (RP) is an application that wants to perform actions on behalf of a user. Those actions might be "read your profile data" or "write to your readinglist". The RP is the thing that does the OAuth dance, obtains a token, and then uses it to execute actions on various Service Providers. A Service Provider (SP) is an application that accepts OAuth tokens for authentication, and in exchange provides some service for the user. For example, https://profile.accounts.firefox.com/ is a Service Provider - you authenticate to it with an OAuth token, and if that token has "profile" scope, it will let you read/write the user's profile data. So the SPs are the things that control what scopes exist and make sense in the ecosystem. IIUC Chris's suggestion above is that you become both an RP and an SP in different parts of the stumbler app: * Make your backend API a Service Provider, so that it accepts tokens with "mozstumbler" scope as sufficient permission to read/write a user's data stored in the stumbler service. * Make the mobile app (and other frontends, e.g. a web-based frontend) a Relying Party, and have it request the following scopes when the user logs in via FxA: * "profile:email" so it can ready the user's email address * "profile:display_name:write" so it can ready/write display name * "mozstumbler" so it can access your backend API I find being explicit about the distinction between RP and SP helpful, hopefully it adds a bit of clarity for you as well. Cheers, Ryan _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
