<html><body><div>Aaah! Oauth 2 is glorified cookie exchange and really shouldn't be used for much. It makes far too many presumptions on other things working correctly. Hell, HAWK is more trustworthy than OAuth 2.

<br>

<br></kneejerk>

<br>

<br>Sent from my Android phone using TouchDown (<a href="www.nitrodesk.com">www.nitrodesk.com</a>)

<br>

<br>

<br>-----Original Message-----

<br>From: Ryan Kelly [rfkelly@mozilla.com]

<br>Received: Thursday, 13 Feb 2014, 7:14PM

<br>To: dev-fxacct@mozilla.org

<br>Subject: Re: FxA-for-web and OAuth

<br>

<br></div><br><div>On 14/02/2014 8:29 AM, Brian Warner wrote:

<br>> Chris and I have been studying the OAuth flows of Google, Github, and

<br>> Twitter, trying to figure out how/if we should use something similar for

<br>> getting the user from 1: an FxA login, to 2: the ability to use various

> internal Mozilla services (RPs) like Marketplace.

<br>> 

<br>> That means somebody shows up at the RP with their possibly-not-FF

<br>> browser, hits some sort of "Sign in with FxA" button, somehow logs into

<br>> their FxA, then winds up back at the RP with enough credentials to

<br>> convince the RP backend server that they deserve access to some subset

> of the RP's data (e.g. their RP account).

<br>

<br>I broadly like this, and it sounds like OAuth2 is a pragmatic compromise

that will help RPs get up and running quicker than a custom protocol.

<br>

<br>The naively-obvious (and therefore likely to be wrong) alternative is to

<br>make FxA a proper BrowserID IdP and let RPs use the persona.org login

flow, maybe with special "forceIssuer" flag or whatever.

<br>

<br>It'd be interesting to enumerate the benefits of the OAuth2 approach

over the already-kinda-exists-if-you-squint BrowserID approach.

<br>

<br>

<br>> So here's a quick sketch of our plan:

<br>> 

<br>> * we use OAuth2 tokens to represent this delegated power over other

<br>>   servers, and a confirmation during the token issuing process to

<br>>   convince the RP that the user+browser has control over the account

<br>

<br>We're proliferating token types here: we have BrowserID assertions, our

own Hawk-authed session tokens, and now OAuth2-style bearer tokens.

<br>

<br>Not necessarily a problem, but potentially a source of confusion.  More

on this below...

<br>

<br>> * we add two APIs to fxa-auth-server. The first (HAWK-authed with the

>   session token) allocates a single-use "precode", tied to the session.

<br>>   The second accepts the precode and returns the uid and email for the

<br>>   account (or error if the precode was unknown). We add one new table

>   (precode, sessionid) to support this.

<br>> 

<br>> * we create a new "fxa-oauth-token" server. This maintains a table of

<br>>   (code, scopes, uid, email), and a second table of (token, scopes,

<br>>   uid). The first API takes (precode, desired scopes), talks to the

>   fxa-auth-server to validate the precode, then allocates+returns code.

>   The second API takes a code and allocates+returns a token.

<br>

<br>Oh, so some sort of "tokenserver" then :-P

<br>

<br>By my count we're up to five distinct well-known endpoints that clients

<br>and/or RPs need to keep track of:

<br>

<br>    * auth server

<br>    * content server

<br>    * profile server

<br>    * oauth token server

<br>    * sync tokenserver

<br>

<br>Is it time to bite the bullet and build out that "discovery api" we've

been talking about?

<br>

<br>> [..snip..]

<br>> 

<br>> ** The second is an OAuth2 token. This can be used by the RP to ask

<br>>    various other services (think profile-server) to provide information

<br>>    or do things that are tied to the user account. The RP includes this

<br>>    token in requests to those services, which can then submit the token

<br>>    to the fxa-oauth-token-server for verification before honoring the

<br>>    request.

<br>

<br>IIRC one of the ideas behind adding "extended claims" to the updated

<br>BrowserID spec, was that we could use them to assert different kinds of

<br>things about the user's identity.  Scopes and permissions could easily

be some of those things.

<br>

<br>BrowserID tokens are strictly superior to OAuth2 tokens in some

<br>important ways.  They can be verified without "phoning home" to the

issuing site, making them less trackable and more network friendly.

<br>

So here's a random thought:  BrowserID over OAuth2.

<br>

<br>Build out the permissions/delegations/whatever system as if BrowserID

<br>had already taken over the world.  Embed permissions, scopes etc in

<br>BrowserID assertions as extended attributes and define a way for RPs to

validate them safely.

<br>

<br>Then, tunnel those things through the OAuth2 dance.  Have the content

<br>and/or oauth-token servers consume the standard OAuth flow but spit out

<br>BrowserID assertions in the place of opaque tokens.  Have them verify

those tokens internally by standard BrowserID verification flows.

<br>

<br>Speak OAuth2 out of practicality, but keep the door open for migrating

piecemeal to a better, JWT/BrowserID based world.

<br>

<br>(This might also avoid having to add APIs for a special "precode",

<br>instead using the existing APIs to just sign certificates with different

<br>sets of attributes.)

<br>

<br>I really have not thought through the details here, and there are

<br>probably a hundred little reasons what it's a bad idea in practice. Yet

I can't help but wonder whether we can have our cake and eat it too...

<br>

<br>

<br>In summary: sounds like a solid plan, let's rock and roll, and maybe we

<br>can transparently do it in a way that keeps the door open for a

decentralized/federated/browserid-based future.

<br>

<br>

<br>  Cheers,

<br>

<br>    Ryan

<br>

<br>_______________________________________________

<br>Dev-fxacct mailing list

<br>Dev-fxacct@mozilla.org

<br><a href="https://mail.mozilla.org/listinfo/dev-fxacct">https://mail.mozilla.org/listinfo/dev-fxacct</a>

<br></div></body></html>