Lets discuss solutions to avoid HTTP Basic Auth but achieving the same solution for the use-case

[ksaadDE]

To quickly provide a summary: As of today seemingly Wiki.js does not support HTTP Basic Auth due to the GraphQL stuff, which seemingly overwrites the Auth header, thus breaking HTTP Basic Auth, according to my high-level understanding after reading the issue #1095.

HTTP Basic Auth is outdated and insecure - why the hack would you want to use it?

Most people use HTTP Basic Auth to

• prevent/block access by search engines and malicious actors
• limiting access to users having the username:password combination
• both of that pretty fast without much configuration

So we want to hide the web app from malicious actors and showing it to our user base. We don't want a lot of configuration for that. Lets see what possible other solutions we hypothetically have.

Possible solutions

IP Whitelisting?

@NGPixel Offered IP whitelisting as possible solution, highlighting the fact that if the edge handles it correctly it would be more secure and reliable than HTTP Basic Auth, which is generally speaking true, with some exceptions.

What are the drawbacks of IP whitelisting looking from the use-case's perspective?

1. We can't allow a partial public by sharing a username:password combination (we can't share our IP lol)
2. When the server itself (e.g. for internal API requests) is allowed (especially in docker setups) it opens the possibility to spoof the IPs or act as the "server's ip" when the server is intruded (even in low priv access)
3. Crawlers present on the same network, like at many cloud providers (which can't really be blocked by any IP whitelisting configurations) can spoof the requesting ip or even bypass IP whitelisting (I experienced that before)
4. Average Joe mostly can't use IP whitelisting, mostly getting dynamic IPs or semi-static ones proxied through the ISP's regional central node (e.g. state-level in Germany) due to privacy laws and routing logic
5. partially it is solvable for Joe using IPv6, which sucks when Joe gets DS-Lite (like most Joes)

nginx's HTTP Basic Auth

Speaking about nginx configurations there is the Oauth Access tokens validation build in (Q1) but this requires some Authentication Provider (and Manager/Server) on top of it. A lot more work compared to nginx's HTTP Basic Auth (Q2)

    ....
    auth_basic           "Administrator’s Area";
    auth_basic_user_file /etc/nginx/.htpasswd; 
    location / {
      ...
    }

For the reverse proxy stuff just an Authorization header needs to be forwarded, which is another line (or two).

nginx's HTTP Digest Authentication

The other option would be using nginx's HTTP Digest Authentication (Q3) which lacks official and reverse proxy support (Q4) and is still using the Authorization header, yet alone it needs further installation (probably even building of the module) and having multiple configuration lines:

auth_digest_user_file /opt/httpd/conf/passwd.digest;
auth_digest_shm_size 4m;   # the storage space allocated for tracking active sessions

location /private {
    auth_digest 'this is not for you';
    auth_digest_timeout 60s; # allow users to wait 1 minute between receiving the
                             # challenge and hitting send in the browser dialog box
    auth_digest_expires 10s; # after a successful challenge/response, let the client
                             # continue to use the same nonce for additional requests
                             # for 10 seconds before generating a new challenge
    auth_digest_replays 20;  # also generate a new challenge if the client uses the
                             # same nonce more than 20 times before the expire time limit
}

nginx's OIDC / OpenID approach

Further nginx offers a OIDC/OpenID approach using the NGINX Management Suite which seemingly requires a lot more work (and nginx+ ?) but is e.g. Keycloak compatible and allows SSO (Q5). It requires a lot more work, as the Auth Providers Endpoint Urls and the following settings must be configured. Not sure how good it works with reverse proxies to dockered containers 🤷

....

# Enable when using OIDC with keycloak
map $http_authorization $groups_claim {
   default $jwt_claim_groups;
}


map $http_authorization $user_email {
   "~^Bearer.*" '$jwt_clientId@$oidc_domain';
   default $jwt_claim_email;
}

# OIDC: use email as a unique identifier
# NOTE: the username is dependent upon claims provided by your IdP
proxy_set_header Nginx-Management-Suite-Auth "OIDC";
proxy_set_header Nginx-Management-Suite-User $user_email;
proxy_set_header Nginx-Management-Suite-Groups $groups_claim;
proxy_set_header Nginx-Management-Suite-ExternalId $jwt_claim_sub;

....

Nginx's Subrequest Result Authentication

There's also nginx's subrequest result authentication (Q6). Less work but will require an auth endpoint, though this could be implemented using wiki js auth stuff.

        location /private/ {
            auth_request     /auth;
            auth_request_set $auth_status $upstream_status;
        }

        location = /auth {
            internal;
            proxy_pass              http:https://auth-server;
            proxy_pass_request_body off;
            proxy_set_header        Content-Length "";
            proxy_set_header        X-Original-URI $request_uri;
        }

Nginx's JWT Authentication

Nginx's JWT Authentication (Q7) seemingly only works in Nginx+ and doesn't offer a nice popup saying "enter your creds". However, it can be connected to an OpenID / Auth Provider like Keycloak, Authentik etc.

    listen 80; # Use SSL/TLS in production

    # protected resource
    location / {
        auth_jwt             "closed site";
        auth_jwt_key_cache   1h;
        auth_jwt_key_request /_jwks_uri;    # Keys will be fetched by subrequest

        proxy_pass http:https://my_backend;
    }

    # url where the tokens are fetched from
    location = /_jwks_uri {
        internal;
        proxy_method      GET;
        proxy_cache       jwk; # Cache responses
        proxy_cache_valid 200 12h;
        proxy_pass        https://idp.example.com/oauth2/keys; # Obtain keys from here
    }

There's also the option to by default have more or less secured tokens and to use nested tokens, next to do validation.

Conclusion

My examples clearly show that HTTP Basic Auth is the best (fastest + reliable) solution for this use-case. It is fast to implement and it solves the task (partially granting access and blocking "unknown" access). There might be something faster / better but I am not aware of anything like that at this time.

Sources

Q1: https://www.nginx.com/blog/validating-oauth-2-0-access-tokens-nginx/
Q2: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/
Q3: https://www.nginx.com/resources/wiki/modules/auth_digest/
Q4: https://forum.nginx.org/read.php?2,290359,290365#msg-290365
Q5: https://docs.nginx.com/nginx-management-suite/admin-guides/authentication/oidc/oidc-keycloak/
Q6: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-subrequest-authentication/
Q7: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication/

Telling people who are well-meaning to switch to another project just because they bring up a very common, legit use-case looks really odd. No matter how well expressed the reasons for rejecting that need are. Instead we all should try to think about possible solutions for this use-case (the problem). Maybe there will be a quick fix that brings both worlds and interests together.

Cheers

[fnafox]

A simple alternative for the presented use case that comes to mind is allowing access only from your internal network and letting people VPN into it. Previously this required some networking know-how but nowadays with stuff like Tailscale this is extremely trivial to set up.

[ksaadDE]

I wanted to stay more on the web server level e.g. nginx. For that reason I did not mention VPNs.

Also, it looks a bit over kill to access usually not very confidential information and just to keep the crawlers out and does not really improve the conditions I described above.

Some VPN services (more or less easy to setup):

1. https://github.com/WireGuard
2. https://github.com/tailscale/tailscale
3. https://github.com/hwdsl2/openvpn-install/blob/master/openvpn-install.sh