mozilla-iam / mozilla-iam/auth0-deploy
Disallow use of locks other than the "hosted lock"
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 6
- Forks
- 21
- Avg merge
- 17h 49m
- Merged PRs (30d)
- 5
Description
We could do this by failing to login and showing a warning with a link to the documentation.
Ex rule (do not use this as-is, it's more of a POC):
function (user, context, callback) {
// This rule will refuse login to any lock that does not appear to be our hosted lock.
// Bypass for xxxx
if (context.clientID === "xxxx") {
return callback(null, user, context);
} else if (user.auth0_client && user.auth0_client.name === "lock-passwordless.js") {
return callback(UnauthorizedError("Please use the hosted lock. See docs at https://wiki.mozilla.org/Security/Guidelines/OpenID_Connect#Session_handling and https://github.com/mozilla-iam/testrp.security.allizom.org/"));
}
callback(null, user, context);
}
The concept here is to set an attribute in the hosted lock that we can check for within a rule. The above rule uses an attribute the modal passwordless lock currently sets (which our hosted lock does not).
It's also important to note that we should only block new clients - as to not break clients that currently do not use the hosted lock yet but have planned to migrate.
Finally here's an example of user data and context information for a login via the modal passwordless lock:
{
"date": "2016-12-22T19:37:54.638Z",
"type": "s",
"connection": "email",
"connection_id": "con_xxxx",
"client_id": "xxxx",
"client_name": "air.mozilla.org",
"ip": "xxxx",
"user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0",
"user_id": "email|xxxx",
"user_name": "xxxx",
"strategy": "email",
"strategy_type": "passwordless",
"auth0_client": {
"name": "lock-passwordless.js",
"version": "2.2.3",
"lib_version": "6.8.0"
}
}
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the proposed Auth0 rule and the hosted lock versus modal passwordless lock behavior described in the issue. Confirm how a hosted-lock attribute can distinguish new clients while preserving existing clients, then verify that unauthorized logins show the documentation warning and that planned migrations remain unaffected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- authentication
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100