Quarkus OIDC: how to support both end user and service account

[jie-huang]

We have services which uses OIDC to handle the auth.

1. For end user, it accepts access token and validate it
2. For service account (another service uses client credential to get access token), access token can be used too

The challenge is, how to make the two systems work together?
There are some APIs they require end user information. So, below config is used.

quarkus.oidc.authentication.user-info-required=true
quarkus.oidc.roles.source=userinfo

But, to make service account work (there is no user info or idtoken from IdP), config must be

quarkus.oidc.authentication.user-info-required=false
quarkus.oidc.roles.source=accesstoken

What is the Quarkus way to support the this use case?

[quarkus-bot[bot]]

/cc @pedroigor (oidc), @sberyozkin (oidc)

[sberyozkin]

@jie-huang Hi, sounds like OIDC multi-tenancy can help, https://quarkus.io/guides/security-openid-connect-multitenancy, one tenant definition (default one for ex) for one type of service, and a custom tenant for another type of service, what do you think ?

[sberyozkin]

Non default tenants can be statically or dynamically created

[jie-huang]

@sberyozkin
I checked that before but getting a little confused.
Basically, there are 3 types of endpoints,

1. end user only (it need access user info)
2. service client only
3. end user and service client

There are two ways to resolve which tenant it should be.

1. based on endpoints path
   That means we can categorize and config endpoint type 1 to fetch userinfo. And let type 2 and 3 not to fetch userinfo.
2. based on the incoming token type.
   If the incoming access token is about service client, do not fetch userinfo. And, in endpoint type 1, server code just need check the end user info is available. Otherwise, reject it.

Which one do you think it is better?
Or, can OIDC just do lazy fetch for userinfo? If the code need access it (by injection), just fetch it (success, or return 401 later if it is not end user case). Then, no extra tenant config is needed. Is that doable?

[sberyozkin]

@jie-huang
Option 1 is simplest, you have 3 endpoints only so, the default tenant configuration can cover one of them, so you'd only need to check 2 paths to pick up specific tenant configurations and return null in case of no match for Quarkus to select the default tenant.
Option 2 is more involved and the token is not verified yet at the point of the tenant config resolution.

Or, can OIDC just do lazy fetch for userinfo? If the code need access it (by injection), just fetch it (success, or return 401 later if it is not end user case). Then, no extra tenant config is needed. Is that doable?

I guess it might be possible to get the injection info which will tell that some user code has a UserInfo injection point. And if only one default tenant is configured then it should be sufficient. Acquiring UserInfo requires a remote call so doing it at the moment the CDI producer is called may require blocking the IO thread

Hi @mkouba, for example, if we have

class Service {
    @Inject
    UserInfo userInfo;
}

is it possible to find out at build time UserInfo.class will be injected ? I recall you and @Ladicek were explaining something about it but awhile back, please remind :-)

[mkouba]

Yes, you can consume the BeanDiscoveryFinishedBuildItem and inspect all injection points in the application - see also the CDI Integration Guide

[sberyozkin]

Thanks @mkouba

[sberyozkin]

Though I'm not sure what exactly it is going to save. Can you prototype these endpoints ? Ex if you have 3 JAX-RS endpoints, 2 of them require user info, one - does not, but you have a single OIDC tenant configuration, then as far as OIDC is concerned, when the endpoint requiring no OIDC is invoked, OIDC won't know if UserInfo is only required for 2 other endpoints, all it will know UserInfo injection point exists.
Mult-tenancy approach is simpler IMHO

[jie-huang]

@sberyozkin thanks for the explanation. BTW, there are not only 3 endpoints, I meant there are 3 types of endpoints. But, I think you are right, Multi-tenancy should be easier now and it put the decision at early phase. Lazy loading put things later and it need the framework to be more flexible to support. And for long term, lazy loading should be better because for code which do not need user info, it improves performance without trigger the remote calling or cache check.