I'm evaluating apiman for a use case and am trying to get my head around a requirement that I have and how that fits in with apiman.

I have normal username/password users that I can use the Keycloak OAuth token system for and that works fine.  I'm interested in using some sort of api key for server to server communication.  Ultimately a customer wants to encode a single key and not get an OAuth token that expires.  If I understand the way that the client API's work I believe that I can implement this through there but I want to make sure I'm understanding correctly.

I think that I would implement two plans.  The "public" plan would include the policies that I want (Oauth and role based authorization) and use Oauth.  Then I would create a client API for the server-to-server communication and that would use a different plan that, assuming that the api key was correct, would not have any other policies.  Obviously that means that the key is very private.

Am I thinking of this the right way?  The advantage of the client API path is that I could shut down a "server" (i.e. the server of a customer interacting with our server) in one shot by unregistering the client.  The APIMAN-282 method would work too in that I could create a single user for the customer and lock that account if I wanted to block access.  Of course, the APIMAN-282 enhancement is still in progress and I'm not sure it will see the light of day.

So the short question is is the two pronged approach the way to go without an APIMAN-282 type of policy?

Thanks for your help.

--