Infrastructure & Engineering

Proxy Authentication with Tinyauth

Otama
2 min read
Progress 11 / 18
Table of Contents

Setting up full-blown SSO can be overkill for a simple homelab. This is where Tinyauth shines—a lightweight “gatekeeper” that makes Proxy Authentication incredibly straightforward.

In this post, I’ll walk through my experience building a Proxy Auth setup using Tinyauth combined with Pocket ID as the OIDC Provider, including real manifest examples.

Basically, I proceeded with the work following this official guide:

Pocket ID OAuth

Use Pocket ID as an OAuth provider in Tinyauth.

tinyauth.app

Workflow

This time, I set it up with the following flow:

  1. Create a provider on the Pocket ID side and obtain the Client ID and Secret.
  2. Deploy Tinyauth using the Client ID and Secret.
  3. Set the Tinyauth endpoint to the provider in the HTTPRoute.

When starting Tinyauth in a deployment, it is designed to provide the Client ID and Secret via environment variables. Therefore, it seemed necessary to set up one Tinyauth instance for each OIDC Provider.

1. Pocket ID Configuration

First, I created an OIDC Client on the Pocket ID side. The Client ID and Secret issued here will be used later, so I noted them down.

2. Deploying Tinyauth

I deployed Tinyauth using the Client ID and Secret obtained from Pocket ID. Below is an example of the environment variable configuration in the Kubernetes Deployment (masked IDs/URLs).

# Tinyauth Deployment env snippet
env:
  - name: APP_URL
    value: "https://auth.example.com"
  - name: SECRET
    valueFrom:
      secretKeyRef:
        name: tinyauth-secret
        key: SECRET


  # Pocket ID OIDC Configuration
  - name: PROVIDERS_POCKETID_NAME
    value: "PocketID"
  - name: PROVIDERS_POCKETID_AUTH_URL
    value: "https://id.example.com/authorize"
  - name: PROVIDERS_POCKETID_TOKEN_URL
    value: "https://id.example.com/api/oidc/token"
  - name: PROVIDERS_POCKETID_USER_INFO_URL
    value: "https://id.example.com/api/oidc/userinfo"
  - name: PROVIDERS_POCKETID_REDIRECT_URL
    value: "https://auth.example.com/api/oauth/callback/pocketid"

3. Configuring HTTPRoute and Middleware

Finally, I set up the Traefik ForwardAuth Middleware and the Kubernetes Gateway API (HTTPRoute).

Traefik Middleware (ForwardAuth)

This Middleware handles auth requests by forwarding them to the Tinyauth service.

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: tinyauth-auth
  namespace: app-namespace
spec:
  forwardAuth:
    address: http://tinyauth.tinyauth.svc.cluster.local/api/auth/traefik
    trustForwardHeader: true
    authResponseHeaders:
      - X-Remote-User
      - X-Remote-Groups
      - X-Remote-Email

Applying via HTTPRoute

The Middleware is applied using the ExtensionRef filter within the HTTPRoute rules.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: app-namespace
spec:
  parentRefs:
    - name: traefik-gateway
      namespace: traefik
  hostnames:
    - "app.example.com"
  rules:
    - filters:
        - type: ExtensionRef
          extensionRef:
            group: traefik.io
            kind: Middleware
            name: tinyauth-auth
      matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: app-service
          port: 80

Regarding Middleware Namespace

Since Middleware cannot be referenced cluster-wide, I decided to place the Middleware in each application’s Namespace.

There seems to be a feature called ReferenceGrant that allows referencing resources in different Namespaces, but I didn’t use it this time. Thinking about keeping application resources in one place and not wanting to create differences across multiple Namespaces when adding apps, I settled on placing it in each Namespace.

Conclusion

By combining Tinyauth and Pocket ID, I was able to successfully introduce Proxy Authentication.

While it might be possible to manage it more smartly using ReferenceGrant, I am currently operating with a configuration where Middleware is placed in each Namespace. Considering my operational rules of “grouping application resources in one place” and “minimizing settings that span multiple Namespaces,” this form feels the most suitable for now.

I hope this helps those who want to set up an authentication infrastructure with a simple configuration.

Related Posts