On 3/06/2015 04:49, Victor Ng wrote: > Thanks! > > The RP vs SP separation was very helpful. That clears up my > understanding quite a bit. > > My next question is - how do I register my android app as a trusted > relier
We just discovered a bug in the oauth server that means you can't do this through the self-service console; send me your client_id and I'll flip the bit by hand in the meantime. > - and how do I register new scopes? Currently you don't need to do anything, just start using the new scope and it should Just Work, assuming you're a trusted relier. > Am I correct that I need to be 'trusted' before I use any scope that is > not explicitly in the list of UNTRUSTED_CLIENT_ALLOWED_SCOPES over here? > > https://github.com/mozilla/fxa-oauth-server/blob/8fd228ad5f77492b3b9341928ec1db6547161bfb/lib/routes/authorization.js#L21 Correct. This is a short-term security measure while we work on a more fleshed-out permissions prompt. Cheers, Ryan > On Tue, Jun 2, 2015 at 2:22 AM, Ryan Kelly <[email protected] > <mailto:[email protected]>> wrote: > > 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
