Keycloak, sharing resources between clients for authorization purposes

We’re developing an application with microservice-based architecture where users can be members of organizations, and within each organization, they may have resource-based access restrictions. An example can be a recruiter who’s a member of several organizations on the platform; in organization A they may see the list of all job postings and interviewers while in organization B they can only see job-posting that they are directly allowed to see.

Structure wise this becomes something like this:
Keycloak resource diagram

All this seems easy to do with Keycloak, we create confidential clients(one for each microservice) and enable resource management on them. However, there are quite some cases when different microservices (i.e., Keycloak clients) need to validate user’s access scopes to the same resource. An example would be a setup where we have 2 microservices one for posting & managing job announcements the other for managing applications and interviews, so job-manager and application-manager . Now, when a new application is submitted, or an interviewer tries to access an application application-manager has to make sure that the user has access to the job posting(resource) configured in the job-manager Keycloak client. Which, I think, is not something Keycloak supports.

Scale wise, we’re speaking about X00k users, 4-5 times that organization users connections, and tens of millions of resources. So to minimize the number of objects we’re creating in Keycloak, we’ve decided to make use of attributes on resources in which we store JSON structures.

So, how one microservice, can verify a user’s access to a resource manager by another microservice?

P.S.
Sorry for the long text, I wanted to provide as much context as possible.

P.P.S.
I posted the same question to StackOverflow: https://stackoverflow.com/questions/60827577/keycloak-sharing-resources-between-clients

P.P.P.S.
I tried posting this to the mailing list but my question was deleted flr some reason.