1123710 - What is the best way to use a OAuth Bearer token in the Firefox Account ecosystem?

Status: RESOLVED WORKSFORME

(Cloud Services :: Server: Firefox Accounts, defect)

Description

[Rémy Hubscher (:natim)]

We are currently implementing a Firefox Account relier or provider.


Vocabulary
==========

- A relier is a service that you connect to using your Firefox Account.
- A provider is a service that both user and reliers can contact to get information about a user when the user authorized the relier to do so (within the use of the oauth token scope)


Flow
====

So at some point one get an OAuth token for a list of scope and use it to contact a relier.

Then the relier validates the token and can use it to get information about the user on provider's.


Question
========

- Should we use the OAuth token to authenticate the user on all the relier/provider endpoints?
   - In that case how long can we cache the token validation?
   - Is it safe to let the user provide its OAuth token on every requests?

- Should we rather use the oauth token to create/connect the user to the relier and provide it with a Session-Token?
   - In that case can we define a standard way to do so? Derive Hawk credentials from the bearer token?

Thank you for your insights.

Comment 1

[Chris Karlof [:ckarlof]]

> Should we use the OAuth token to authenticate the user on all the relier/provider endpoints?
  
Yes, ideally, all authentication for FxA connected services should be handled through FxA OAuth tokens. However, for a token to be valid for authenticating an endpoint, that token needs to have a scope associated with it that is for the endpoint. So for example, it would be dangerous to use an FxA OAuth token for the Loop API if the token just has the "profile" scope. If were to use OAuth to authenticate the the Loop API, we would need those tokens to have the "loop" scope.

> In that case how long can we cache the token validation?

Ideally, you don't. You verify it for each API call. I think some degree of caching is fine if the added latency impacts performance. Ryan Kelly is also working on some account server notifications to help make this better and let service providers do more caching of validation safely.

> Is it safe to let the user provide its OAuth token on every requests?

Safe enough. However, I want us to move from issuing long-lived access tokens to issuing long lived refresh tokens, which can be used to get shorter lived access tokens. For now, you submit the access token on each request.

> Should we rather use the oauth token to create/connect the user to the relier and provide it with a Session-Token?

I'd prefer not, but that's how some relying services are currently implemented, e.g., Loop. There's nothing terrible about, but it leads to a "everyone does their own session auth in their own way" problem.

Comment 2

[Nick Alexander :nalexander [he/him]]

> > Is it safe to let the user provide its OAuth token on every requests?
> 
> Safe enough. However, I want us to move from issuing long-lived access
> tokens to issuing long lived refresh tokens, which can be used to get
> shorter lived access tokens. For now, you submit the access token on each
> request.

I agree with ckarlof: moving towards short-lived service-specific oauth tokens is preferable to requiring a Hawk token-exchange and Hawk request-signing.  I'm concerned about web clients implementing Hawk; I'd be more on board with Hawk if it was easy to include a browser library that did the right thing with Hawk-signed XHR requests out of the box.

Comment 3

[Rémy Hubscher (:natim)]

> I'd be more on board with Hawk if it was easy to include a browser library that did the right thing with Hawk-signed XHR requests out of the box.

We have that :)

https://github.com/spiral-project/daybed.js/blob/master/index.js#L43-L46

Ok Chris, thank you for your insight about this. We are implementing it that way for readinglist.

Comment 4

[Alexis Metaireau (:alexis)]

> I'm concerned about web clients implementing Hawk; I'd be more on board with Hawk if it was easy to include a browser library that did the right thing with Hawk-signed XHR requests out of the box.

Nick, we currently rely on Hawk for a few projects which have a web-client part, and it's working pretty well. Do you think we're missing something important there?

Comment 5

[Nick Alexander :nalexander [he/him]]

(In reply to Alexis Metaireau (:alexis) from comment #4)
> > I'm concerned about web clients implementing Hawk; I'd be more on board with Hawk if it was easy to include a browser library that did the right thing with Hawk-signed XHR requests out of the box.
> 
> Nick, we currently rely on Hawk for a few projects which have a web-client
> part, and it's working pretty well. Do you think we're missing something
> important there?

Nothing in particular.  My concern is just that Hawk is fiddly and a pain in the ass; it wasn't clear to me that the XHR API gave enough control over the request headers to calculate the hash correctly.  If we have a library, in production, a) kudos and b) concern withdrawn.