<div dir="ltr">Hello,<div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So the short question is is the two pronged approach the way to go without an APIMAN-282 type of policy?</div><div><br></div><div>Thanks for your help.</div><div><br></div><div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Scott Dunbar<div>Cell: 303 667 6343</div></div></div>
</div></div>