Service Account behavior (expiration and error)

What happened?

Issue #1
I configured a ServiceAccount in Pomerium with an expiration date in the past. In the Pomerium Console, the token is reported as expired since X days ago.

I used this token to perform a call to an API on a route secured with Pomerium and the call was successful, Pomerium did not reject the expired token.

Issue #2
When accessing a SOAP API on a route secured with Pomerium without an authentication token, Pomerium answers with HTTP code “302 Found” and the location header set to the login page “https://pomerium.external/.pomerium/sign_in?pomerium_expiry=1660304994&pomerium_idp_id=&pomerium_issued=1660304694&pomerium_redirect_uri=&pomerium_signature=”

I noticed that for a GRAPHQL API, in the same situation, we get HTTP code “401Unauthorized” and no redirection. This is the best answer for an API call. It seems to be related to the request header “Accept”, for GRAPHQL it is set to “application/json” and for SOAP it is set to “application/soap+xml” or “application/xml”.

What did you expect to happen?

Issue #1
I expect Pomerium to deny access with an expired token.

Issue #2
I expect to get response “401Unauthorized” for my SOAP API endpoint. How can I get this behavior ?

What’s your environment like?

We have a Kubernetes cluster using Traefik as Ingress Controller and Pomerium for forward auth. We have configured Pomerium to use Keycloak as idp.

  • Pomerium version: 0.18.0
  • Kubernetes version: 1.20.11
  • Traefik version: 2.8.0
  • Keycloak version: 15.0.1

What’s your config.yaml?

address: :80
authenticate_service_url: https://pomerium-authenticate.external
authorize_service_url: http://pomerium-authorize.internal
databroker_service_url: http://pomerium-databroker.internal
dns_lookup_family: V4_ONLY
forward_auth_url: http://pomerium-proxy.internal
idp_client_id: <hidden>
idp_client_secret: <hidden>
idp_provider: oidc
idp_provider_url: https://keycloak.external
insecure_server: true
routes:
    - from: https://api.external
      pass_identity_headers: true
      policy:
        - allow:
            or:
                - domain:
                    is: mydomain.com
      prefix: /services/api
      to: http://api.internal

After talking to Bobby, I understand that Issue #2 is the expected behavior today.

About Issue #1, is there any plan to fix it soon ? Being able to use a token which is expired is a real security concern, can you advise what should we do ?

Fix was released part of v0.20.0