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
- and how do I register new scopes?

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

When I tried to login with scopes set to "profile:email
profile:display_name mozstumbler", the login screen hangs just prior to
redirect.  I've filed https://github.com/mozilla/fxa-oauth-server/issues/264
with details.




On Tue, Jun 2, 2015 at 2:22 AM, Ryan Kelly <[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

Reply via email to