<div dir="ltr"><div><div><div><div>Thanks!<br><br></div><div>The RP vs SP separation was very helpful. That clears up my understanding quite a bit.<br></div><div><br></div></div>My next question is - how do I register my android app as a trusted relier - and how do I register new scopes?<br><br></div>Am I correct that I need to be 'trusted' before I use any scope that is not explicitly in the list of <span class="">UNTRUSTED_CLIENT_ALLOWED_SCOPES over here?</span> <br><br><a href="https://github.com/mozilla/fxa-oauth-server/blob/8fd228ad5f77492b3b9341928ec1db6547161bfb/lib/routes/authorization.js#L21">https://github.com/mozilla/fxa-oauth-server/blob/8fd228ad5f77492b3b9341928ec1db6547161bfb/lib/routes/authorization.js#L21</a><br><br></div>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 <a href="https://github.com/mozilla/fxa-oauth-server/issues/264">https://github.com/mozilla/fxa-oauth-server/issues/264</a> with details.<br><br><br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 2, 2015 at 2:22 AM, Ryan Kelly <span dir="ltr"><<a href="mailto:rfkelly@mozilla.com" target="_blank">rfkelly@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2/06/2015 04:26, Christopher Karlof wrote:<br>
> A scope, which is just a string, like “profile”, is a permission that is<br>
> associated with a token. A token with a “profile” scope means that token<br>
> has the permission to read and write the user’s profile. The<br>
> authentication flow would for using such a token would be something like:<br>
><br>
> 1) A client sends a request to the FxA Profile API, including the OAuth<br>
> token as a bearer token.<br>
> 2) The Profile server extracts the token, verifies it [1], and gets the<br>
> lists of scopes associated with it.<br>
> 3) The Profile server verifies that “profile” is on the list of scopes,<br>
> which is the scope associated with the FxA Profile API. If the “profile"<br>
> scope is missing, that means this token does not have the appropriate<br>
> permission to use the FxA Profile API, and the request should be rejected.<br>
><br>
> If you want to use FxA OAuth to authenticate your API, we need to agree<br>
> on a scope that represents your API, e.g., “mozstumbler”. Then, in the<br>
> login flow for your app you would request the scopes “mozstumbler<br>
> profile” [2]. This means when the login completes, your application<br>
> would obtain a token for the user with permission to use your backend<br>
> API (i.e., “mozstumbler”) and permission to use the profile API for that<br>
> user (i.e., “profile”). This token can now safely be used from the<br>
> mobile app (i.e., to use the mozstumbler) or from the backend.<br>
><br>
> A trusted relier (which I think MozStumbler would be) can currently<br>
> request any scope it wants (I believe this is still the case), even if<br>
> it doesn’t exist yet. Longer term we should probably lock this down a<br>
> bit, to improve error messaging at the least.<br>
<br>
</div></div>(Adding my 2c to the explanation in the hope that it's helpful...)<br>
<br>
The tricky thing with understanding scopes is that there are two<br>
distinct types of application in an OAuth ecosystem: Relying Parties<br>
and Service Providers.<br>
<br>
A Relying Party (RP) is an application that wants to perform actions on<br>
behalf of a user. Those actions might be "read your profile data" or<br>
"write to your readinglist". The RP is the thing that does the OAuth<br>
dance, obtains a token, and then uses it to execute actions on various<br>
Service Providers.<br>
<br>
A Service Provider (SP) is an application that accepts OAuth tokens for<br>
authentication, and in exchange provides some service for the user. For<br>
example, <a href="https://profile.accounts.firefox.com/" target="_blank">https://profile.accounts.firefox.com/</a> is a Service Provider -<br>
you authenticate to it with an OAuth token, and if that token has<br>
"profile" scope, it will let you read/write the user's profile data.<br>
<br>
So the SPs are the things that control what scopes exist and make sense<br>
in the ecosystem.<br>
<br>
IIUC Chris's suggestion above is that you become both an RP and an SP in<br>
different parts of the stumbler app:<br>
<br>
* Make your backend API a Service Provider, so that it accepts tokens<br>
with "mozstumbler" scope as sufficient permission to read/write a user's<br>
data stored in the stumbler service.<br>
<br>
* Make the mobile app (and other frontends, e.g. a web-based frontend) a<br>
Relying Party, and have it request the following scopes when the user<br>
logs in via FxA:<br>
<br>
* "profile:email" so it can ready the user's email address<br>
* "profile:display_name:write" so it can ready/write display name<br>
* "mozstumbler" so it can access your backend API<br>
<br>
<br>
I find being explicit about the distinction between RP and SP helpful,<br>
hopefully it adds a bit of clarity for you as well.<br>
<br>
<br>
Cheers,<br>
<br>
Ryan<br>
</blockquote></div><br></div>