mozilla / fxa-oauth-server

OAuth server for Firefox Accounts

Firefox Accounts OAuth Server

This code is now managed in the fxa-auth-server repository. This repository is maintained for historical purposes only.

fxa-oauth-server's Issues

link api.md from readme

from #9

Fix broken fragment refs in api.md

I'm seeing stuff like: "[GET /v1/client/:id][client]" and "After having received a [code][]".

Move repo to "fxaccounts" team

@warner could you help with this? I wrongly put it in identity-owners.

GET /v1/client/:id returns imageUri in camel case, but other endpoints return values in snake case

For "consistency".

Change /token to /pubkey

blocks #7

Add action parameter to GET /authorization

This allows reliers to signal what page they'd like the content server to show: signin or signup. This parameter should be included in the redirect to the content server and handled there.

[oauth] A few outdated packages

Follow up to c1d06eb which updated a few of the packages.

---

Steps to reproduce:

1. $ npm i -g david
2. $ david

Actual results:

Outdated Dependencies

• bluebird (package: 1.2.2, latest: 1.2.4)
• hapi (package: 4.0.0, latest: 4.0.3)
• mysql (package: 2.1.1, latest: 2.2.0)

npm install --save [email protected] [email protected] [email protected]

Outdated Dev Dependencies

• jshint-stylish (package: ~0.1.5, latest: 0.2.0)
• nock (package: ~0.27.3, latest: 0.28.3)

npm install --save-dev [email protected] [email protected]

Expected results:

Not sure if we want to update a few of the modules before we launch. Most of these outdated dependencies are fairly minor patch revisions.

But then again, keeping up to the latest package numbers is always a tricky game.

Subscribe to notifications from the auth server

Currently the auth server notifies via SQS/SNS when accounts are deleted. Also: mozilla/fxa-auth-server#710

Extend GET /v1/client/:id to return relier's redirect_uri

For error case handling in the sign up flow we want to re-direct the user back to the relier without blindly trusting the redirect_uri provided in the URL.

Change authorization endpoint to POST

from #9

Add npm-shrinkwrap

In the spirit of mozilla/fxa-auth-server#603 and mozilla/fxa-content-server#685, lets add npm-shrinkwrap support to this repo to make sure everything is locked down.

Plus, then we can eventually do stuff like this: mozilla/fxa-auth-server#617; Integrate npm-shrinkwrap validator for possibly vulnerable modules.

123done doesn't display signed in user email upon oauth sign in

1. goto: https://123done.dev.lcip.org/
2. click sign in, and sign in with an existing acct
3. you will be redirected back to 123done

actual: 123done page doesn't display the email of the firefox account

expected: it used to and should. I'm writing automated tests for this and can't validate pass case.

Change "client" to "relier"?

It's more jargon-y, but it's also less generic. This may improve code readability of our oauth client [1] code, e.g.: https://github.com/mozilla/fxa-content-server/pull/888/files#r11439595

[1] Case in point. I ran into the overloading problem just in this meta github issue!

Make `scope` consistent

from #9

Need UI for user-selected scope permissions

I'm not quite clear on where this functionality lives or whether it's distributed among several components.

Once an app makes a request with a given set of scopes, the scopes not on the whitelist are subject to user approval, as I understand it. This issue is a request for the team to figure out a) where this functionality lives, and b) what it looks like.

If these decisions have already been made and I'm just hopelessly behind the times, pointers to mock-ups and code would be appreciated.

Profile server is returning an empty object when presented with a valid Bearer token

After a bearer token is exchanged, I'm attempting to fetch the email address from

GET https://profile.dev.lcip.org/v1/email
Authorization: Bearer <token>

returns an empty object

{}

123done showing error bar on IE: Unable to get property 'logged' of undefined or null reference

Initial metrics collecting

@kparlante How do this look? I see this initial bug filed. Will it just scrape the logs, or do we need a log summary?

error if scope is empty

verifying email page displays [object object]

1. goto https://123done.dev.lcip.org/
2. click sign up
3. enter new acct and pw
4. verify email in your inbox
5. look at the verification page
   actual: it says you're ready to use [object object]

api.md review

A few notes from my initial review of api.md

• We use scope in the params for /oauth/authorization and scopes in the response of /oauth/token. Can we make those both scope or scopes?
• Add a link to api.md in README.md
• Add a short description of what each endpoint does before its request/response information
• Can we make state mandatory? I'd like for reliers to implement this be default.

Great start, @seanmonstar!

Clean up Oauth design doc for distribution

There are some notes and "ramblings" in there I'd like to cleanup before we distribute it to our relier friends:
https://github.com/mozilla/fxa-oauth-server/wiki/oauth-design

When it's ready, drop it in the doc section near the top of this etherpad:
https://id.etherpad.mozilla.org/fxa-marketplace

@warner assigned

GET authorization should redirect to content-server

from #9

Use bearer token as signing cred

Current: Imagine foo.com gets a token for Alice, with permissions read profile, write bankaccount. When making a request to the profile server, passing this token to it also happens to give the profile server permission to write to bankaccount of Alice.

Instead, it'd be great if instead of passing the token to attached services, the token was used to sign a request and append the hmac. The oauth server could verify the hmac, without the attached service ever getting their robotic hands on the sacred token.

"Unknown client" error when logging into 123done.dev.lcip.org

Verified username and password are correct. Usiong wrong pasword gives "Incorrect password." Using wrong user name gives "Unknown account." Using both correct gets "Unknown client."

Someone check the client_id on 123done.dev.lcip.org, please?

Tracking: Choose a way to deploy an oauth server into the FxA stage environment

The proposals on the table are as follows:

1. awsbox -- pros: we know how to do it, it's dead simple to set up, and there is some configurability. cons: it doesn't know how to set up hosts in the stage.mozaws.net domain, and it's different from the mechanism currently used to deploy the other servers. Also different from what's being used in production
2. CloudFormation -- pros: It's what @jrgm is currently using, I believe. It's also quite close to what's being used in production. cons: Requires a bit of configuration/puppet work.
3. dcoates's stack-builder -- pros: @vladikoff has been working to enable this very thing, so most of the hard stuff is done. cons: it's yet another deploy mechanism to master.

I have a mild leaning toward 2, but am willing to be convinced otherwise. Anybody else have thoughts?

Chose an OAuth 2.0 framework

Possible options:

• https://github.com/thomseddon/node-oauth2-server
• https://github.com/jaredhanson/oauth2orize
• others?

/cc @seanmonstar @warner @vladikoff

Implement Client Registration API

• GET /client/:id
• figure out authentication
• route to create a new client
• route to update client details
• cli program to access API (until we make a UI)

More flexible policies for redirect_uri

I'd like to support more flexible policies around redirect_uri

1. Multiple redirect URIs, e.g., http://localhost/ and https://marketplace.dev.server/ for a client_id issued to Marketplace developers
2. Allow subdirectories, i.e., not exact matching, like: https://developer.github.com/v3/oauth/#redirect-urls

package.json isnt valid (invalid author value)

Found in commit ffc62b7

---

Steps to reproduce:

1. Copy the package.json file contents.
2. Go to http://package-json-validator.com/
3. Paste package.json contents.

Actual results:

{
  "valid": false,
  "errors": [
    "author field should have name"
  ],
  "warnings": [
    "Missing recommended field: keywords",
    "Missing recommended field: contributors"
  ],
  "recommendations": [
    "Missing optional field: homepage",
    "Missing optional field: engines"
  ]
}

Expected results:

Add the following fields to package.json:

• "author": "Mozilla (https://mozilla.org/)", - currently is blank string for author.
• "homepage": "https://github.com/mozilla/fxa-oauth-server", - currently not specified.

If this is going to go on npm, we should add keywords so users can find it easily via a search.

Not sure if we want to add engines (and at least "node" version). Here's the current package.json values for fxa-{content,auth}-server:

  "engines": {
    "node": ">=0.10.0"
  },

via https://github.com/mozilla/fxa-content-server/blob/master/package.json

  "engines": {
    "node": "0.10.x"
  },

via https://github.com/mozilla/fxa-auth-server/blob/master/package.json

RPs need a way to get user UID

Should this be automatic? Should it be an additional scope? profile:uid?

Add token verify endpoint

Once a token has been given to client, and they submit it to attached services, those services need to verify that the token is valid for the permission being asked for.

Something to keep me up at night: someone evil could just spam this endpoint with random tokens to discover them, and save the ones that are correct.

This would be safer if the token were used to sign a request, instead of being submitted plainly, which is what #7 is all about.

Provide curl examples for each API call in api.md

Similar to what the FxA auth server's api.md provides.

tag v0.1.0 for ops

blocks #35

Summary log line per request for heka/es/kibana stack

We want a summary log line ala the verifier and the auth-server, for app specific event based logging in heka/es/kibana (and possibly other downstream metrics consumers).

mozilla/browserid-verifier#24

The fields should include:

• Timestamp
• http response code
• error number (0==success, error codes for failures)
• client (using this server's terminology... the rp or service making use of this server)
• standard fields like hostname, pid

A couple requirements from the ops/data guys:

• send to stdout
• use same format as browserid-verifier and auth-server summary logs

@seanmonstar : let me know if the fields sound right. Not sure if it should be client or client_id
/cc @mostlygeek, @trink, @whd

Getting 404s on client.json when no locales are set

Found in https://oauth-ui.dev.lcip.org/ver.json (commit 9ce7d1549984e6ed7a0d4204122c503aca7ed209)

{"version":"0.10.0","commit":"9ce7d1549984e6ed7a0d4204122c503aca7ed209"}

---

Steps to reproduce:

1. Go to your preferences and remove all your locales.
2. Go to http://123done.dev.lcip.org/.
3. Open your developer tools. Specifically the Network tab.
4. Click [Sign in with your email] button.

Actual results:

I'm getting a 404 on https://oauth-ui.dev.lcip.org/i18n/client.json and everything is blank.

Expected results:

Fallback to en-US or en-us or en_us or en, or however l10n works.

use v2 of verifer

Make `state` required

from #9

Add client details endpoint

Content-server needs to display details about the client requesting authorization.

GET /v1/client/:id

Document API endpoints

Using Non-English characters as client name

When I using Non-English characters as client name on config/dev.json.
The page appear garbled.

I fixed it by setting the "default-character-set" as utf8 for mysql.
Is it a bug?
Or could I setting it on json configuration file?

Deployment setup

@mostlygeek How's this look for next week?

Does api need to be versioned? /v1/oauth/token?

If the answer is no, we just close up here.

auth-server restricts client IDs in email to 16 characters

The OAuth server currently uses 16 bytes as hex, which results in 32 characters, which doesn't pass auth-server validation. We can loosen the auth-server validation or shrink the client ID size here. I spoke breifly with @ckarlof today and we figured 8 bytes should be enough for unique client IDs.

/cc @warner @dannycoates

Security review

Before this is generally available, it needs to undergo Mozilla security review. @warner and @seanmonstar will lead that.

Document request parameters for GET /authorization in api.md

Add __heartbeat__

Accessing client data returns 400 even when client id exists

Unsure how to name the issue.

When I try to use 123done against current master of fxa-{auth,oauth,content}-server, I get a few problems.

I get two types of error:

1. GET /v1/client/:client_id, error: "Invalid request parameter", w/ db driver mysql, error in log says "the length of client_id must be 16 characters long"
2. POST /v1/authorize, returns application error "ECONNREFUSED", w/ db driver memory

After some fiddling around, I discovered that files in lib/routes/ are using in validation, path, client_id the configuration file values and doubles it like so ...length(config.get('unique.id') * 2). When I remove the * 2, I stop getting the "must be 16 characters" error. But the 2nd problem arises later.

As far as I can see, I do not think that my own code changes are part of the issue. Also, I tried the following on both versions (latest, and my changes applied on top). If you want to see them you can have a look at my changes documentation at WebPlatform.org wiki in Projects/SSO/Adapt_Firefox_Accounts_for_WebPlatform#Changes.

The following is a log of my debugging attempts for a consumer client with 532441e9, both the client (123done) and the fxa-oauth-server instance has their respective entries. Other components are installed and works fine.

Setup

Running current master version of all components. Detailing only 123done and fxa-oauth-server here.

• MacOS 10.9.2, with brew installed+updated.
• node 0.10.28
• npm 1.4.9
• 123done http://localhost:8081
• oauth-server http://localhost:9010
• content-server http://localhost:3030
• Normal sign-in works outside of OAuth flows.

FxA OAuth server setup

Create id and secrets, based on (docs/clients.md)

node
var crypto = require('crypto'), tempGenerator = function(len){ return crypto.randomBytes(Math.ceil(len)).toString('hex').slice(0,len); };
> tempGenerator(8)
'532441e9'
> tempGenerator(32)
'cafdb4ac8b47166404516050213dc559'

fxa-oauth-server client entry in config/dev.json:

// Same as master version of the file, showing only differences
// ... database is on a separate Vagrant VM.
"clients": [{   
  "id": "532441e9",
  "secret": "cafdb4ac8b47166404516050213dc559",
  "name": "123done-3",
  "imageUri": "http://localhost:8081/img/transparent-logo.png",
  "redirectUri": "http://localhost:8081/api/oauth",
  "whitelisted": true
}],
"mysql": {
  "host": "33.33.32.5"
},
"db": { "driver": "mysql" }

Deleted database, re-created fxa_oauth database (otherwise it tries to re-create client entries).

Start fxa-oauth-server

 grunt server --node-env=dev

FxA OAuth server has log saying (truncated as much as possible):

fxa.bin.server.DEBUG: Starting with config: {
  "contentUrl": "http://localhost:3030/oauth/",
  "publicUrl": "http://127.0.0.1:9010",
  "server": {
    "host": "127.0.0.1",
    "port": 9010
  },
  "unique": {
    "clientSecret": 32,
    "code": 32,
    "id": 8,
    "token": 32
  }
}
fxa.db.mysql.VERBOSE: createDatabase
fxa.db.mysql.VERBOSE: changeUser
fxa.db.mysql.VERBOSE: creatingSchema
fxa.db.DEBUG: connected to [mysql] store
fxa.db.DEBUG: Loading pre-defined clients: [
  {
    "id": "532441e9",
    "secret": "cafdb4ac8b47166404516050213dc559",
    "name": "123done-3",
    "imageUri": "http://localhost:8081/img/transparent-logo.png",
    "redirectUri": "http://localhost:8081/api/oauth",
    "whitelisted": true
  }
]
fxa.db.mysql.DEBUG: getClient: [83,36,65,233]
fxa.db.mysql.DEBUG: registerClient: client already has ID? [83,36,65,233]
fxa.db.mysql.DEBUG: registerClient 123done-3 532441e9
fxa.db.mysql.DEBUG: registerClient: success [532441e9]

Things sounds good so far.

123done Setup

On 123done code, adjusted client like so config.json:

{
 "client_id": "532441e9",
 "client_secret": "cafdb4ac8b47166404516050213dc559",
 "scopes": "profile",
 "redirect_uri": "http://localhost:8081/api/oauth",
 "auth_uri": "http://localhost:9010/v1/authorization",
 "oauth_uri": "http://localhost:9010/v1",
 "profile_uri": "https://profile.dev.lcip.org/v0"
}

In my case, i had to change the port in the 123done server.js, it runs on port 8081.

Starting 123done:

npm start

Running and debugging the issue

When I run:

curl http://localhost:9010/v1/client/532441e9
{"code":400,"errno":109,"error":"Bad Request","message":"Invalid request parameter","validation":{"source":"path","keys":["client_id"]}}

When I check the logs, it doesnt say anything.
Once I change fxa-oauth-server, in the file lib/error.js:49

console.log('wpd1', response, response.output.payload);

After deleting database (because that's not part of the present issue), after restarting and testing the same cURL call, I get same error, but the logs talks more:

wpd1 { [Error: the length of client_id must be 16 characters long]
  data: 
   { [Error: the length of client_id must be 16 characters long]
     details: [ [Object] ],
     _object: { client_id: '532441e9' },
     message: 'the length of client_id must be 16 characters long' },
  isBoom: true,
  output: 
   { statusCode: 400,
     payload: 
      { statusCode: 400,
        error: 'Bad Request',
        message: 'the length of client_id must be 16 characters long',
        validation: [Object] },
     headers: {} },
  reformat: [Function] } { statusCode: 400,
  error: 'Bad Request',
  message: 'the length of client_id must be 16 characters long',
  validation: { source: 'path', keys: [ 'client_id' ] } }

The message, made me wonder that the key is 8 chars, why it says 16.

So, I went in the lib/routes/ files and found found:

validate: {
  path: {
    client_id: Joi.string()
      .length(config.get('unique.id')*2) // hex = bytes*2
      .regex(HEX_STRING)
      .required()
  }
},    

After changing all places in config.get('unique.id')*2) in lib/routes/ and removed the *2. Deleting fxa_oauth, and restarting, I get.

curl http://localhost:9010/v1/client/532441e9
{"code":400,"errno":101,"error":"Bad Request","message":"Unknown client","clientId":"532441e9"}

Once I remove the database backend from fxa-oauth-server in the config/dev.json, I get a different behavior (besides the need to drop the database and create a new one to restart).

curl http://localhost:9010/v1/client/532441e9
{"name":"123done-3","image_uri":"http://localhost:8081/img/transparent-logo.png","redirect_uri":"http://localhost:8081/api/oauth"}

But when I use 123done, this time I get a "Internal server occured" at POST /v1/authorization, log says:

fxa.assertion.ERROR: error verifying assertion Error: connect ECONNREFUSED
    at errnoException (net.js:904:11)
    at Object.afterConnect [as oncomplete] (net.js:895:19)
wpd1 { [Error: connect ECONNREFUSED]
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  isBoom: true,
  data: null,
  output: 
   { statusCode: 500,
     payload: 
      { statusCode: 500,
        error: 'Internal Server Error',
        message: 'An internal server error occurred' },
     headers: {} },
  reformat: [Function] } { statusCode: 500,
  error: 'Internal Server Error',
  message: 'An internal server error occurred' }

Since its not a mysql db backend anymore, i'm lost.

Thoughts?

Handle action parameter in GET /authorization

Instead of forwarding it to the content server (#50), let's terminate it in GET /authorization and redirect to the appropriate endpoint on the content server (/oauth/signin or /oauth/signup, https://github.com/mozilla/fxa-content-server/blob/oauth/app/scripts/router.js#L68)

Add description to each endpoint

from #9