Couper as BFF (backend for frontend) for an SPA, acting as an OAuth2 client

[johakoch]

I thought about Couper as a BFF (backend for frontend), with Couper authorizing requests by an SPA to a resource server (RS).

                                +------+
                                |  AS  |
                                |      |
                                +------+
                                  ^  |
                                  |  |
                      POST /token |  | {"access_token":"...",...}
                                  |  |
+---------------------------------|--|---+
|            Client               |  v   |
|+-----+                       +--------+|
|| SPA | Set-Cookie: tok="..." | Couper ||                           +----+
||     |<----------------------|  BFF   ||                           | RS |
||     |                       |        ||                           |    |
||     | Cookie: tok="..."     |        || Authorization: Bearer ... |    |
||     |---------------------->|        |--------------------------->|    |
|+-----+                       +--------+|                           |    |
+----------------------------------------+                           +----+

The RS responds to unauthorized requests with 401. Couper then should somehow handle this situation by starting a token retrieval process eventually requesting an access token from the authorization server (AS), storing the token as a cookie in the browser, and then "translating" the cookie in the SPA's resource requests into an Authorization: Bearer header.

definitions {
  backend "rs" {
    origin = "https://resource.server.com"
    path = "/**"
    set_request_headers = {
      Authorization = "Bearer ${request.cookies.tok}"
    }
  }
  # ...
}

Now the question is: How can I configure Couper to handle a specific (error) status code?
I tried using expected_status:

  api {
    base_path = "/api"

    endpoint "/**" {
      proxy {
        backend = "rs"
        expected_status = [200,...,400,...,500,...] # not 401
      }

      error_handler "unexpected_status" {
        # start token retrieval process
      }
    }
  }

But I have to list every status code that the RS can return apart from authorization problems, so that only the authorization problem is handled by the error_handler "unexpected_status" {}.

Any idea how to solve this differently?

[johakoch]

What about a new attribute unexpected_status = []?

      proxy {
        backend = "rs"
        unexpected_status = [401]
      }

      error_handler "unexpected_status" {
        # start token retrieval process
      }

[johakoch]

Configuring an unexpected_status in a proxy in a wildcard endpoint (where all sorts of valid status codes can occur due to the endpoint proxying to potentially a lot of backend API endpoints) looks more meaningful to me than configuring an expected_status.

[johakoch]

See issue #831