mozilla-iam / mozilla-iam/auth0-deploy

Disallow use of locks other than the "hosted lock"

Open
#89 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Auth0 Lock Auth0 Rules enhancement
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.