Enabling Server to Server Applications on Couper OIDC Gateway

[frederik-b]

Hi,
I'm interested in documentation or otherwise help to enable server to server communication
on an existing couper installation specifically using the Two-legged OAuth flow.

If i am not mistaken this is also called the client_credentials flow.
However I cannot find documentation or other informative resources
for the combination of couper and this topic.

I would need to enable this on a couper gateway system that is already configured to authenticate users (using google as 3rd party).
So a configuration supporting only client_credentials will not work for my specific use case.

[malud]

Hi,
are we talking about the same issue as pointed out in #774 ?

1. Does your service runs within the same k8s cluster?
2. Let's discuss why you would like to enforce a navigational flow (oidc) for service/server communication.
3. In general you will have the option to extend the OIDC configuration to add additional endpoints or even ports for other authentication methods and introduce JWT, Basic Auth or mTLS.

[frederik-b]

This is about the same system as the one in #774 , but I want to tackle the problem in a different way.

1. The server is in a different cloud.
2. I don't want to force this, we were assuming that we will not be able to change that it currently only allows oidc auth.
3. That sounds like a reasonable way to go forward, is there an example on how to allow 2 separate auth mechanics for the same backend?

[johakoch]

For server-to-server communucation, please see the OAuth2 client credentials example at https://github.com/coupergateway/couper-examples/tree/master/backend-authorization-oauth2.

[frederik-b]

Thanks that is part of the documentation that I am looking for.
I am not sure however how to enable any of this without replacing the current configuration block.

The examples always only allow for one grant_type / one oauth2 block per endpoint at a time.

[johakoch]

The use-cases for OAuth2 "client on behalf of a specific user" (authorization code) and "client on behalf of itself" (client credentials) are quite different. So there's no way to have them both together in one.

[frederik-b]

Is this a limitation of OAuth2 or a limitation of Couper?
I believe that it is a rather common scenario to have an API
that is used by users and clients on behalf of users
and system level userless services at the same time.

[johakoch]

As the discussion topic is about the Couper OIDC Gateway: OIDC is about authenticating users and uses the OAuth authorization code grant, not the client credentials code grant (which is applicable for server to server communication).

In OAuth terms, the Couper OIDC gateway is both a client (endpoint "/_couper/oidc/start" {} and endpoint "/_couper/oidc/callback" {}) and a resource server (endpoint "/**" {}, requiring the token, created and stored at the /callback endpoint, for accessing the backend; and not other kinds of tokens). But it is not a "third-party backend request authorizer" like backend/oauth2 (which is a not-per-user OAuth2 client, and may use the client credentials grant).

I believe that it is a rather common scenario to have an API that is used by users and clients on behalf of users and system level userless services at the same time.

This sounds like it is about a resource server in OAuth2 terms. You can configure such a "protected resource" using the jwt access control, which does not care whether the token was requested via autorization code or client credentials grant.