User:Clouserw/AMO/Auth: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| Line 1: | Line 1: | ||
{{draft}} | {{draft}} | ||
== builder.addons.mozilla.org == | |||
# {{done|}} Builder flips to using browserid as its only authentication (for both admins and regular users). Builder continues to retrieve account id, homepage, etc. from the AMO database directly. (Since both AMO and browserid have independently confirmed the user owns the address this remains secure). | |||
# AMO builds a simple API end point for user data including the information browserid is using (and specifically *not* password data). This API endpoint is behind oauth and accessible only to builder's | |||
existing oauth key. ('''todo:clouserw''': file this bug) | |||
# Builder uses that API and we remove the direct database access from builder. | |||
# AMO switches to using browserid as its primary authentication | |||
== addons.mozilla.org == | |||
=== Current flow and challenges === | === Current flow and challenges === | ||
| Line 15: | Line 31: | ||
[1] The single password field is for legacy reasons only. It would be possible to use other forms of verifying a users identity here also. | [1] The single password field is for legacy reasons only. It would be possible to use other forms of verifying a users identity here also. | ||
=== Open Questions === | |||
- How can a user register for a new account on builder? | |||
Revision as of 21:34, 5 January 2012
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
builder.addons.mozilla.org
- [DONE] Builder flips to using browserid as its only authentication (for both admins and regular users). Builder continues to retrieve account id, homepage, etc. from the AMO database directly. (Since both AMO and browserid have independently confirmed the user owns the address this remains secure).
- AMO builds a simple API end point for user data including the information browserid is using (and specifically *not* password data). This API endpoint is behind oauth and accessible only to builder's
existing oauth key. (todo:clouserw: file this bug)
- Builder uses that API and we remove the direct database access from builder.
- AMO switches to using browserid as its primary authentication
addons.mozilla.org
Current flow and challenges
User is given a single button for login/register and a link underneath for admins/editors. Regular users click the "log in/register" button, go through browserid flow, and are logged in. Privileged users click the link, are prompted with the local authentication form, and are logged in after that. This is a potentially confusing split for the end users and also leads to two code paths which I'd like to avoid. Security has made it a requirement that privileged users must give an additional token (with more requirements) before they are authenticated to AMO so browserid is not good enough.
Proposed Solution
- User is shown a login/register button that launches browserid
- User authenticates (regular users are done at this point)
- If User is privileged they are shown a second form with a single password field[1]
- User must authenticate here before they are allowed to continue. Failure to authenticate results in no session created.
This provides us with a single branch out of the "normal" flow but fulfills the additional requirements Security has requested.
[1] The single password field is for legacy reasons only. It would be possible to use other forms of verifying a users identity here also.
Open Questions
- How can a user register for a new account on builder?