Please generate prod OAuth client credentials for prod Reading list service

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: edwong, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Comment hidden (empty)
(Reporter)

Updated

4 years ago
Blocks: 1141155
(Reporter)

Updated

4 years ago
No longer blocks: 1141155
Depends on: 1141155
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?
Flags: needinfo?(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".
Flags: needinfo?(rnewman)
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.
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.
Flags: needinfo?(rnewman)
Flags: needinfo?(rhubscher)
Flags: needinfo?(edwong)
(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
Flags: needinfo?(rnewman)
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".
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.
Flags: needinfo?(rhubscher)
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.
> 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
Summary: Please generate prod OAuth tokens for prod Reading list service → Please generate prod OAuth client credentials for prod Reading list service
(Reporter)

Comment 10

4 years ago
> 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
Flags: needinfo?(edwong)
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.
> * Readinglist server will ship with its fxa-oauth/* endpoints preffed off so we don't expose additional attack surface

Copy that.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.