Closed Bug 1148094 Opened 9 years ago Closed 6 years ago

fxa-oauth-server returns 400 rather than 401 for many assertions

Categories

(Android Background Services Graveyard :: Reading List Sync, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nalexander, Unassigned)

References

Details

I discussed this with rfkelly in #fxa a few days ago; filing here.  My original complaint was that a bogus assertion (like "ASSERTION") gave 400/109.  I'm now seeing a valid assertion, but signed against the wrong FxA auth server, giving 400/104.  (That is, submitting a prod FxA assertion to a stage oauth server.)  Those both need to be 401, so that clients have a hope of distinguishing "legit client errors, fix code" from "authentication errors, re-authenticate and then fix settings".

IRC log:

21:43 nalexander: rfkelly: why would I get a 400/109 from fxa-oauth-server when I submit a bogus assertion?
21:43 nalexander: rfkelly: how can that not be a 401?
21:43 rfkelly: looks
21:43 nalexander: rfkelly: https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md
21:44 nalexander: rfkelly: that is, the server API is making it hard for clients to distinguish "configuration is bad (client id, etc)" from "my state is bad" (401).
21:44 rfkelly: how is the assertion bogus?
21:44 nalexander: rfkelly: 'cuz I generated it locally with certificate "BAD CERTIFICATE"
21:45 nalexander: rfkelly: I'm trying to test a particular oauth 401 flow.  And I expected to get a 401 from the oauth server when I came with a bad cert.
21:45 rfkelly: so, possibly it's bailing out while trying to parse the assertion, rather than when trying to verify it, hence unexpected error
21:45 rfkelly: I agree it should be a 401
21:45 nalexander: rfkelly: because how do I distinguish bogus cert from expired cert?  They should both look like 401, since I'm unauthed.
21:45 nalexander: rfkelly: I have a single day deadline for this RL oauth work, so I'm goign to pretend 400 is 401 for nwo.
21:46 rfkelly: ok
21:46 nalexander: rfkelly: but if it made it to a bug, I'd appreciate it :)
21:46 rfkelly: that can probably happen ;-)
21:49 rfkelly: nalexander: if there's formatting errors in the assertion, it could catch it here and trigger the 400 rather than 401:
Argh, sorry Nick, I did actually file this when you asked me to but evidently I forgot to /cc you :-(

See also: https://github.com/mozilla/fxa-oauth-server/issues/234
Closed on github.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.