Jwt + login for Github Auth

1. My Caddy version (caddy -version):

Latest.

2. How I run Caddy:

I am testing a dockerised version of caddy locally to serve a static .md file.

a. System environment:

Dockerised version directly from github/caddyserver/caddy.

b. Command:

My Caddyfile:

:2015 {
    gzip
    browse
    jwt {
        path /
        redirect /login     
    }
    login {
        github client_id={$github_client_id},client_secret={$github_client_secret}
        success_url /
        jwt_expiry 24h
        cookie_expiry 2400h
    }
    ext .md
    markdown
}

3. The problem I’m having:

After declaring the environment variables on docker run and exposing on port 2015 all roots are being redirected to a /login path, showing the Github template.

Following the authentication flow, the following is echoed by the server logs:

time="2019-10-21T11:35:49Z" level=info msg="successfully authenticated" type=application username=xxxx

My Github Authorization callback URL is http://localhost:2015/login/github

The screen passes me back to the /login page.

Can I get some help on why my request isn’t being passed onto the success_url route?

5. What I already tried:

I have looked around all available examples and tried multiple variations of the above - with no luck!

Hi @KieranM, welcome to the Caddy community!

I wonder whether the redirect is actually coming from Caddy or if it’s Github issuing that redirect.

You could try passing the intended redirect location to Github?

e.g. github client_id={$github_client_id},client_secret={$github_client_secret},redirect_uri=https://example.com/ (replacing example.com as appropriate)

Per: https://github.com/tarent/loginsrv#config-options

Hi @Whitestrake, thank you!

I have added the optional redirect with no success. The request continues to be authenticated but I am returned to the \login route as opposed to the \ <== success url route.

I am re-reading the loginserv project to see if I have missed something, any other suggestions would be amazing - thank you!

1 Like

Changing the Caddyfile structure to:

:2015 {
    gzip
    browse
    jwt {
        path /login
        redirect /login     
    }
    login {
        github client_id={$github_client_id},client_secret={$github_client_secret}
        success_url /
    }
    ext .md
    markdown
}

This correctly goes through the Github OAuth if you hit the /login route and passes you onto the success URL. However, if you hit the success URL you bypass the OAuth …

Am I missing a step where the JWT token is checked when hitting any route other than /login?

path should be /, if you want to secure the whole site. By setting path /login, you’re telling jwt not to secure any paths outside of /login.

Thanks for highlighting that @Whitestrake, on further inspecting of the page I can see that the jwt token is being successfully set:

  • GET request http://localhost:2015/login/github?code=XXX&state=XXX

But then …

  • GET request to the success URL http://localhost:2015/contained the following in the Response Header:

Www-Authenticate: Bearer realm="",error="invalid_token"

The token itself is correct, using jwt.io.

Also, the Caddy logs still inform me that I have successfully been authenticated. Any ideas on where my mistake might be?

Just to check, your browser is sending the token, right? It’s in your request headers when you revisit the main URL?

Might have to start simplifying things and sort out where things break down. Can you try with a htpasswd file or simple auth and see if it still doesn’t authenticate properly?

It isn’t in the request header, it is in the Set-Cookie property of the Response Header.

Using the example and a Caddyfile that looked like this:

:2015 {
    browse
    jwt {
        path /
        allow sub bob
    }
    login / {
        simple bob=secret,alice=secret
    }
    ext .md
    markdown
}

I am getting a 401with the following authentication error:

Www-Authenticate: Bearer realm="",error="invalid_token"

lol.

Any pointers?

So you get the Set-Cookie response header, but your browser never actually sends the cookie back?

I have gotten to the bottom of this now. This issue (https://github.com/BTBurke/caddy-jwt/issues/42) covered my problem case and this commit would update the documentation to help (https://github.com/schnatterer/gollum-galore/commit/7e66d4a15f1722995a498b4679e11d4affec7d96#diff-04c6e90faac2675aa89e2176d2eec7d8R64).

Essentially, in local development you needed to switch cookie_secure false for login. I couldn’t find this in the documentation and the silent failures of JWT along with the incorrect “successful authentication” messages from my server made this pretty opaque!

I hope this thread helps anyone else who finds themselves in the same position :raised_hands:

Thanks for your efforts @Whitestrake

3 Likes