This includes both the service (presumably a web service), and the actual validation logic behind it.
Summary: Server needs to validate auth token → MEET Server needs to validate auth token obtained from Firefox Accounts
Actually, this is _just_ the validation logic.
Actually, the MEET server does not need to know about browserid assertions. What needs to be sent there (and validated) is an auth token issued by the tokenserver, and a secret. The node uses the Signing Secret to validate the Auth Token. The node calculates the Token Secret from its Master Secret and the Auth Token, and checks whether the signature in the Authorization header is valid. All the steps are defined here: http://docs.services.mozilla.com/token/user-flow.html
We're discarding the use of the token server for now; we need to call the remote verifier (or eventually get the certificates locally to do local verifications) to check the assertions are valid.
Summary: MEET Server needs to validate auth token obtained from Firefox Accounts → Loop Server needs to validate bid assertion obtained from Firefox Accounts
FTR, For local verifications we could use https://github.com/mozilla/browserid-local-verify
Created attachment 8383069 [details] [review] code & tests
Attachment #8383069 - Flags: review?(adam)
Add a way to do remote verification of the browserid assertions, and do some mocking in order to avoid the roundtrip during the tests. Paired some bits of this with :nperriault.
Comment on attachment 8383069 [details] [review] code & tests Looks good, under the assumption that we'll fix the split between call-url and registration in bug 978455.
Attachment #8383069 - Flags: review?(adam) → review+
Solving with the same patch that landed in bug 971991
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 971991
OK. Verifying as a duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.