Setup with OIDC

[shishkin]

Can you elaborate on the "misuse" part in more detail?

I was looking into a home k8s setup with various "admin" dashboards and "family user" apps. I wanted to stay fully self-hosted (so no Auth0, Cognito or social IdPs) and have the simplest (least moving parts) and lightest (least resources) solution possible. After dismissing Keycloak, Authelia, Authentik. For now I've picked Dex as the lightest identity provider with OIDC support and OAuth2-Proxy for glueing it to Traefik ingress. The idea is for Dex to store users/passwords/groups and do authentication, while proxy should read the identity and groups from claims and do authorization on per application basis for admin apps and just forward OIDC directly to OIDC-aware user apps. I still find this setup overcomplicated and would prefer ingress controller to have an OIDC-aware middleware built-in, but I could not find one in OSS ecosystem.

Do you consider this scenario a "misuse" of OIDC? How would you solve it with Heimdall?

[dadrus]

To be honest - yes.

Here is my reasoning:

OIDC is an extension to OAuth2. And OAuth2 is about authorization. To be more precise about delegation of rights to access data of a user to an application. To be even more precise - you as a user allows an application A to access your data managed by an application B. This application A is named "client" by OAuth2 and the application B is named resource server by OAuth2. So you as a user authorizes application A to access your data managed by the application B. Which authorization you as a user, also named "Resource Owner" by OAuth2 makes depends on the needs of the application A (the client). These needs are described by the client in the so called scopes (like read/write something. E.g. you can authorize codecov to read your repositories in github), which are sent by the client the the auth provider, which then asks you (the resource owner), whether you agree with that after the auth provider validated that you are you (the authentication step). If you agree - provide that authorization, the scopes are "added" to the access token, which the application A (client) receives. Now it can use this token to communicate to application B (resource server) to access your data. Sometimes however, the application A (client) needs also the information about you. Here OIDC comes into the game, as it defines (among a couple of other things) an ID token, which holds information about you. Which information it can contain depends again on the authorization you gave to the application A (client).

What you however have is the following: You don't have an application A (client) and B (resource service) which are completely independent. The opposite is the case, your application is a combination of the client and the resource service. And since this is the same application, you don't have the requirement for rights delegation addressed by OAuth2 and OIDC. The only thing you need is the information about the authenticated used. But if you only need the information about the authenticated user, why are you using OIDC? Just to get the ID Token? But that thing will expire sooner or later. Usually after a couple of minutes. This way, you have to care about refreshing that information to understand whether your user i still logged in. Do you need this complexity? I would say no. But let us stop for a moment, what was the idea in using OIDC here? I bet, this is because it supports transport of information related to the user over domain boundaries, thanks to those callbacks and redirects, which are part of the protocol and which is not possible if the system responsible for managing identities lives in another technical domain compared to your service. So, at the end you've just used OIDC for that purpose of cross-domain user information transport, which is just a mechanism used by OAuth2 and OIDC to transfer those tokens, but not what these two protocols are about. There are other protocols, which are not related to authorization delegation and which use the same transport mechanisms if you rely on an identity management system, which lives outside of our technical domain. Examples are CAS or SAML. Both of them address authentication and can also include authorization information related to what the user is allowed to do (compare that to OIDC/OAuth2 - authorization here is about what the client is allowed to do). So at the end you've used OIDC for something it is not designed for. This is why I've written, the protocol is very often misused.

In your case you don't even have two different domains, so why using a "system", which needs those redirect mechanisms. The easiest way to go in your case would be to use something, which just issues the old good cookies and then making use of these in your system.

[shishkin]

Thanks @dadrus! This is indeed a great and detailed explanation.

Regarding your references: Is CAS even a thing? It doesn't seem to have implementation support beyond its reference implementation. And even e.g. Keycloak treats OIDC as SAML successor.

I agree that a cookie-based auth behind a single parent domain would be ideal for my case. What would be your recommendation for a simple implementation on kubernetes?

[dadrus]

I've seen CAS used in production environments a couple of times in the past. But you're right it hasn't gained much popularity, even it is a nice and a pretty simple way to enable passing information about the authenticated user across domain boundaries.

I have no clue, why the maintainers of Keykloack treat OIDC as a successor for SAML. As I've written above these protocols address completely different domains.

Back to your question. Almost every oss identity management implementation out there focuses on SSO use cases via either SAML or OIDC. Unfortunately, this is the current trend. So theory meets practice. The only exception right now, I'm aware about is Kratos from Ory. But it is an API only product, which requires integration, respectively glue code which would then implement the desired UIs.
If you want something simple wich can be used out of the box, look for a service, which can issue "good old" cookies, which your services can then consume to get information about the authenticated user. In your case everything is anyway running within the same domain (according to my understanding), so you don't need those complex approaches implemented by SAML and OIDC. Since, as you've written, your apps do however rely on, respectively expect access tokens you would then have to translate the information from the cookie into the expected format (e.g. using heimdall). As it might be challenging to find a simple IAM service without enforced usage of SAML or OIDC, and you decide for OIDC, you may find an oss OIDC relying party implementation for envoy, which could then be integrated with it using an external authorization filter. You may also find something for traefik, but will have to recompile it. I remember having seen some in the past for both. That would simplify your setup a lot. You are also very welcome to contribute to heimdall 😉, there is a corresponding ticket (#185) waiting for being implemented, which would allow you achieving the same but with any of the ingress controllers of you choice. BTW. Traefik has such functionality built in in their commercial offering; same is also true for ambassador.