1141166 - Please generate prod OAuth client credentials for prod Reading list service

Status: RESOLVED WORKSFORME

(Cloud Services :: Operations: Deployment Requests - DEPRECATED, task)

Comment 1

[Ryan Kelly [:rfkelly]]

It's not clear exactly what needs to be done here.

IIUC the readinglist *server* does not need oauth credentials, since it only has to consume oauth tokens but does not need to generate them

The readinglist *client* code will need some sort of credential, but I thought they already had one for existing oauth stuff inside firefox.

Edwin or Richard can you please provide some more detail on precisely what's needed here?

Comment 2

[Richard Newman [:rnewman]]

We already have the client producing prod OAuth tokens from prod FxA credentials using oauth.accounts.firefox.com (unfortunately still using the "profile" scope, but so it goes).

The prod RL service needs to be configured or provisioned to be able to verify those tokens, in the same way that the dev RL deployment accepts OAuth tokens from one of the dev/stage/stable OAuth services.


That might need zero work, it might need simply a config param, or it might need something else. I think this bug is "make it work".

Comment 3

[Ryan Kelly [:rfkelly]]

Thanks Richard.  I'm pretty sure this will "just work" as long as the prod RL server is passing oauth tokens to the prod OAuth server for verification.

Comment 4

[Ryan Kelly [:rfkelly]]

After chatting with :natim in IRC, there is a web client for readinglist that uses the flow here to authenticate:

  http://readinglist.readthedocs.org/en/latest/authentication.html

In which case, the RL server *will* need a client_id and client_secret to support it.  So a couple of questions to make sure I get my head around the situation:

Edwin:    is this readinglist web client something we need to support in the production environment?
Richard:  do the FF clients use any of the flow linked above for parameter discovery?
Remy:     is the server capable of running with None as a client_id if we don't need that flow?

I don't want to push back on this and it's no problem to generate client credentials, but I want to make sure we all agree on whether they're necessary and how they'll be used.

Comment 5

[Richard Newman [:rnewman]]

(In reply to Ryan Kelly [:rfkelly] from comment #4)

> Richard:  do the FF clients use any of the flow linked above for parameter
> discovery?

We get an FxA assertion in the usual manner.

We use the OAuth 1.0 client to talk to the prod OAuth server's "authorization" endpoint, passing in a fixed client ID (3332a18d142636cb), a scope ("profile", because apparently "readinglist" isn't a thing), and the FxA assertion.

We use the resultant OAuth token to talk to the RL server.

The only values that are not hard-coded are the assertion and the token. Nothing is discovered, and there is no web flow.

I think that means the answer to your question is "no", but knowing for sure means understanding what you mean by parameter discovery, which I don't :D

Comment 6

[Ryan Kelly [:rfkelly]]

By "parameter discovery" I meant hitting this endpoint to discover e.g. the oauth server URL to use:

  http://readinglist.readthedocs.org/en/latest/authentication.html#custom-flow

So that is indeed a "no".

Comment 7

[Rémy Hubscher (:natim)]

The readinglist server can work as a Oauth provider and though does not need any client credentials to work.

We need to fix the web flow problem, but maybe the solution is to configure the web client to have a client_id and client_secret and get back the oauth credentials directly on client side.

This week, we will change the scope from profile to readinglist and remove not needed anymore fxa-oauth endpoints.

We will still need production credentials for the web-app if Edwong validates its deployement in production.

Comment 8

[Ryan Kelly [:rfkelly]]

Great, thanks Rémy.

> maybe the solution is to configure the web client to have a client_id
> and client_secret and get back the oauth credentials directly on client side

This sounds like a good approach, and it will just be a question of timing w.r.t. the initial production push.

> remove not needed anymore fxa-oauth endpoints.

FWIW I quite like the `/fxa-oauth/params` endpoint as an easy way to learn about the server dependencies.  I hope we can standardize on an approach like this for all service providers at some point.

Comment 9

[Rémy Hubscher (:natim)]

> FWIW I quite like the `/fxa-oauth/params` endpoint as an easy way to learn about the server dependencies.  I hope we can standardize on an approach like this for all service providers at some point.

Can you tell me about the needed information in there?

Here are the one for the loop-server: http://docs.services.mozilla.com/loop/apis.html#post-fxa-oauth-params

Comment 10

[Edwin Wong [:edwong]]

> Edwin:    is this readinglist web client something we need to support in the production environment?

There are no plans for a production supported reading list web client

Comment 11

[Ryan Kelly [:rfkelly]]

Thanks Edwin.  Summing up, here's how things stand as I understand:

* We don't need readinglist-specific client credentials provisioned for production release
* Client code will use dedicated platform-specific credentials that are already provisioned
* Readinglist server will ship with its fxa-oauth/* endpoints preffed off so we don't expose additional attack surface
* We can revisit the above if/when we want to ship the web client to production.

Please speak up if that doesn't sound right.  Otherwise, I think we can safely close this bug out.

Comment 12

[Rémy Hubscher (:natim)]

> * Readinglist server will ship with its fxa-oauth/* endpoints preffed off so we don't expose additional attack surface

Copy that.