Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Some notes for running `login-with` locally.

Here are some notes for playing around with login-with locally.

login-with assumes that it will be accessed over https. Since we are just playing around with it, we want to run it locally. We don't want to mess with setting up nginx as a reverse proxy.

We can use socat as a quick reverse proxy.

First, we need to create a certificate socat can use. (Ideally, socat would create a certificate for us every time it runs, but it doesn't look like that functionality exists...) openssl is used to create the ceritificate:

$ openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.key

This creates the files cert.pem and cert.key.

You can pass these files to socat:

socat -vv openssl-listen:3433,reuseaddr,fork tcp4:localhost:3000

This sets up socat so it listens on port 3433 for SSL connections, unwraps the SSL, and forwards the connection to localhost port 3000.

Now, we need to make sure that login-with is listening on port 3000. Run it with docker:

$ docker run -i -t --rm -p 3000:3000 \
    -e NODE_ENV=production \
    -e LW_SUBDOMAIN= \
    -e LW_SESSION_SECRET=foobar \
    -e LW_JWT_SECRET=foobarbaz \
    -e LW_TWITTER_CONSUMERKEY=lTxxxxxxxxxxxxxxxxxxxUhC \

The above assumes that we are actually running on a machine with IP address It is also making docker expose port 3000 on the local machine. (We saw this earlier in the socat command.)

The LW_TWITTER_* values come from creating an application on Twitter. You need to go to Twitter's developer console to create these. LW_SUBDOMAIN is normally the subdomain where login-with is running from.

Now that socat and login-with are both running, we can try accessing login-with in the browser:

$ firefox ''

Here is the application flow:

  1. Connect to login-with.

  2. login-with redirects to the Twitter authentication API. Something like the following:

  3. If you authorize the application, you get redirected back to login-with (well, actually socat).

    The request looks something like the following:

    GET /twitter/callback?oauth_token=P6XXXXXXXXXXXXXXXXXXXXXXX78U&oauth_verifier=sdwqxxxxxxxxxxxxxxxxxxxxxxxxxPi HTTP/1.1
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
    Cookie: connect.sid=s%3AxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtB9I
    Upgrade-Insecure-Requests: 1
  4. login-with then redirects you to the URL you specified in the success query parameter. The repsonse looks like this:

    HTTP/1.1 302 Found
    Set-Cookie: jwt=eyJ...Fso; Max-Age=864000; Domain=.168.56.22:3433; Path=/; Expires=Sun, 22 Apr 2018 07:09:27 GMT; HttpOnly; Secure
    Set-Cookie:; Max-Age=864000; Domain=.168.56.22:3433; Path=/; Expires=Sun, 22 Apr 2018 07:09:27 GMT; Secure
    Vary: Accept\r
    Content-Type: text/html; charset=utf-8\r
    Content-Length: 94\r
    Date: Thu, 12 Apr 2018 07:09:27 GMT\r
    Connection: keep-alive\r

You can see in this last step that login-with adds two cookies. One is called jwt and the other is called profile.

The information in the jwt cookie is as follows:

token:	314...g3
tokenSecret:	gdU7...5Y
profile.username:	mytwitteruser
profile.provider:	twitter	mytwitteruser
iat:	1523577889

This is only available over HTTPS.

The profile cookie is JSON-encoded. It lists simple things like the username, etc. This can be accessed from JavaScript.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment