问题
I'm developing a microservice in C++ (for low latency reasons), and I'm beginning to dive into OpenID and Keycloak. Developing in C++ means I've almost no library support for OpenID, but I've (hopefully) the all the low level details working (like proper JWT verification). I've to do all the communication flows and redirects myself.
So much as a background. Keep that in mind because I need to know and implement details which usually a library will hide for a developer.
There are three parties in my application:
- A web client W
- Microserice A
- Microservice B
General communication between those three: The web client W could be either a frontend UI or a mobile device using just the API as a service without having any sort of frontend. W connects to microservice A to manipulate and consume data from it. Microservice A exchanges data with microservice B and vice versa. W does not need to know about B.
So far I thought of the following architecture:
- For the Web Client to Microservice A communication I'd use dedicated users and clients with access type "Public" in Keycloak to allow user/pw logins
- For the Microservice A to Microservice B communication I'd use Access Type Bearer because they never initiate any login
Please advise if you think that does not sound right. My actual question is however what kind of login flow(s) is required and which step there are in between which I may miss:
Is it ok to have an endpoint for the login on microservice A https://servicea.local/login which redirects the requests of the web client to OpenID / Keycloak. E.g. the web client sends username, password, client id and grant typeto the OpenID token request endpoint http://127.0.0.1:8080/auth/realms/somerealm/protocol/openid-connect/token ?
Should the client take the token and add it to all subsequent calls as authorization token?
Should the Microservice implement a callback to retrieve the authorization information?
Should the flow instead be changed for the client to service communication to provide an access code to he service which it exchanges with an access token?
回答1:
I would aim for an architecture where the role of your C++ APIs is just to verify tokens and serve data.
The client side is a separate solution though, requiring its own code for logging in + dealing with authorization codes and getting tokens. This should not involve your API - so to answer your questions:
- Not recommended
- Yes
- No
- No
These days all logins should occur via the system browser, whether you are writing any of these. This client side code is probably not C++ and often requires more work than that to build the API:
- Web UI
- Mobile UI
- Console / Desktop App
If it helps my blog has a lot of write ups and code samples about these flows. In the following post, notice that the API is not called until step 13, once all login processing has been completed by the web client.
OAuth Message Workflow
回答2:
Authentication (delegating to Keycloak) and then getting Token should be done by your UI by directly contacting keycloak and that token should be passed on from UI to A to B
Here are the OIDC endpoints that keycloak provides
https://www.keycloak.org/docs/latest/server_admin/index.html#keycloak-server-oidc-uri-endpoints
来源：https://stackoverflow.com/questions/60160447/openid-redirect-vs-bearer