Authentication of Micro Frontend (part 1 — non-oauth2)
This is part 1, of a 2 part series. A poor-man’s solution for authorization. In this part, I m putting together a poor man’s solution to securing micro-frontend and or micro-services architecture.
Preface
Businesses are multiple faceted; thus there is a need for different applications that encapsulate workflow, administer by different teams. These applications in today's buzzwords fall into 2 categories MicroServices and newer one Micro frontend.
Motivation
Make self sufficient teams! Unblock teams by isolating teams to create valuable services for the business. That means they can run their own schedule, deliver and own the entire software stack. (reference: https://micro-frontends.org/). But keep distinct flavor of the organization.
Monolithic UI w/ multiple services
Frontend team would build one single UI and have services built out by domain focused teams. Enter a heavy UI team running their own schedule.
Separate web-apps for micro services
In this architecture you create separate applications that are barely linked together by links. This architecture allows somewhat separation of teams; however it creates disjointed User Experience. Overtime experiences fall apart and looks awkward.
Micro Frontends for Microservices
In this architecture; the team is responsible for end to end = front end, application tier and backend. This is not a new concept. Anyone who has ever put a banner ad on their website have already somewhat done micro frontend. Albeit, here, it is by a focused team from same org.
Trust challenges
In the micro frontend & micro-services architecture one of the biggest challenge is trust.
Let’s role play.. user on Catalog Micro-frontend, is trying to checkout a T-shirt for $15.99. How would checkout team trust that request was:
- Originated from a approved Micro-app.
- The user had the intent and was approved in source system to perform this transaction.
- The user hopping onto Checkout Service is actually the same user.
Characteristics of a solution
- Trust chain, if microservice B trusts microservice A; then requests are trusted.
- Trust user, at each call to microservice user needs to be validated that it is the same user.
- Unique requests (state changers), for every put, post and delete request a new unique request id is required from MicroService A while sending a message to MicroService B.
Enter Asymmetric Encryption
A potential solution to this quagmire is the use and sharing of certificates.
Re-enter catalog team and checkout team…
Public key
Checkout team would provide a public certificate to catalog team. It is a secret certificate that is used on app server by catalog team.
It simply expects the catalog team to always encrypt main data points:
- User Id (shared Id)
- Request Id (optional: for put, post & delete requests).
Private key
Checkout team receives the request and decrypts with correct private key. Server validates the logged in user id matches user id that was sent and if the request was not HttpGet then is it a unique request Id.
Decentralized trust
Finally you have a mesh of trust where each team is empowered to approve what micro services and micro frontends can call it. Thus you have truly unblocked each team to have its own mandate.
The Last mile a single screen on UI becomes a rich eco-system where different teams can securely deliver their services and interoperate with other teams.
Next
In the next article I will try to share how an oauth2 based architecture can take the inadvertent pain that would arise in administering the above solution.
