Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question: API Key in Authorization: Bearer header #321

Open
mitja opened this issue Feb 20, 2024 · 2 comments
Open

question: API Key in Authorization: Bearer header #321

mitja opened this issue Feb 20, 2024 · 2 comments
Assignees
Labels
need triage question Further information is requested

Comments

@mitja
Copy link

mitja commented Feb 20, 2024

I would like to support client authentication with API Keys stored in an Authorization: Bearer header

If I understand correctly, the API key can be passed via the X-Api-Key header.
I would like to be able to use the Authorization: Bearer header, instead or in addition to that.

The rationale is, that I could use Caddy with Caddy Security as an API Gateway for a self-hosted OpenAI API compatible Rest API (eg. as provided by Ollama). This would be immediately usable by the large number of clients, such as OpenWebUI. The OpenAI API uses Authorization: Bearer.

As per the discussion in issue 116 the following config makes auth with header X-Api-Key possible:

security {
  authorization policy mypolicy {
    with basic auth portal myportal realm local
    with api key auth portal myportal realm local
  }
}

On the other hand, Token validation can be activated with Authorization: Bearer with this config:

{
  security {
    authorization policy mypolicy {
      validate bearer header
    }
  }
}
curl --insecure -H "Authorization: Bearer JWT_TOKEN" -v https://localhost:8443/myapp

Is there a way to "merge" the two or set one header based on the other to achieve the following?

curl --insecure -H "Authorization: Bearer API_KEY" -v https://localhost:8443/myapp
@mitja mitja added need triage question Further information is requested labels Feb 20, 2024
@mitja mitja changed the title question: API Key in Bearer question: API Key in Authorization: Bearer header Feb 20, 2024
@mitja
Copy link
Author

mitja commented Feb 21, 2024

I think it can be solved with two Caddies behind each other. The first copies the API token from the Authorization header to the X-Api-Key header. The second protects the route(s) with caddy-security.

I have checked with httpbin that the X-Api-Token header is set correctly with this Caddyfile:

:80 {
    @apikey {
        header_regexp apikey Authorization "Bearer (?P<apikey>[a-f0-9]+)"
    }
    
    route @apikey {
        reverse_proxy httpbin:8080 {
            header_up +X-Api-Key {http.regexp.apikey.apikey}
        }
    }
}

This docker-compose.yml file:

version: '3'
services:
  httpbin:
    image: mccutchen/go-httpbin
    command: ['/bin/go-httpbin', '-port', '8080']
  reverse_proxy:
    image: caddy
    depends_on:
      - httpbin
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
    ports:
      - "8000:80"

And this command:

curl -H "Authorization: Bearer 123456789" -c -U http://localhost:8000/headers

Response:

{
  "headers": {
    "Accept": [
      "*/*"
    ],
    "Accept-Encoding": [
      "gzip"
    ],
    "Authorization": [
      "Bearer 123456789"
    ],
    "Host": [
      "localhost:8000"
    ],
    "User-Agent": [
      "curl/8.4.0"
    ],
    "X-Api-Key": [
      "123456789"
    ],
    "X-Forwarded-For": [
      "172.25.0.1"
    ],
    "X-Forwarded-Host": [
      "localhost:8000"
    ],
    "X-Forwarded-Proto": [
      "http"
    ]
  }
}

Maybe it even works by just protecting the specific route with caddy-security in the same single Caddy, but I am unsure if the header values are copied early enough.

Haven't tried it, yet, with caddy-security, though.

@faithiyanuekun22
Copy link

Roqqu Account Reactivation

Repository owner deleted a comment from faithiyanuekun22 Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need triage question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants