Author: Sriram Panyam

Multi-factor authentication (MFA) is a method of computer access control in which a user is granted access only after successfully presenting several separate pieces of evidence to an authentication mechanism — typically at least two of the following categories: knowledge (something they know), possession (something they have), and inherence (something they are). 

MFA is being adopted by more and more organizations these days because putting it in place greatly increases security. The user also feels more secure. So, why use role-based multi-factor authentication (MFA)? Modern organizations are typically subject to a wide range of regulatory and contractual legal obligations for the security of the data they create and use. 

So far in our series on modern microservices, we have built:

• A simple gRPC service
• Added a REST/HTTP interface exposing gRPC service RESTfully and showing a glimpse of the gRPC plugin universe
• Introduced Buf.build to simplify plugin management

We are far from productionalizing our service.  A production-ready service would (at the very least) need several things:

We concluded the last article by generating a gRPC Gateway service to act as a proxy in front of our gRPC chat service. This service would convert familiar REST/HTTP requests from clients to/from our gRPC services. We also briefly discussed how the protoc utility orchestrates various plugins to generate various artifacts: solely via stdin and stdout.

In the same vein, our REST/HTTP gateway was generated by using the grpc-gateway plugin and annotating our RPC methods by http method, bindings, and parameter details (for further customization). We also generated OpenAPI specs for our generated gateway service so it could be consumed via the SwaggerUI, too.

As a quick recap, in Part 1:

• We built a simple gRPC service for managing topics and messages in a chat service (like a very simple version of Zulip, Slack, or Teams).
• gRPC provided a very easy way to represent the services and operations of this app.
• We were able to serve (a very rudimentary implementation) from localhost on an arbitrary port (9000 by default) on a custom TCP protocol.
• We were able to call the methods on these services both via a CLI utility (grpc_cli) as well as through generated clients (via tests).

The advantage of this approach is that any app/site/service can access this running server via a client (we could also generate JS or Swift or Java clients to make these calls in the respective environments).

Client-server communication is a fundamental part of modern software architecture. Clients (on various platforms — web, mobile, desktop, and even IoT devices) request functionality (data and views) that servers compute, generate, and serve. There have been several paradigms facilitating this: REST/Http, SOAP, XML-RPC, and others.

gRPC is a modern, open source, and highly performant remote procedure call (RPC) framework developed by Google enabling efficient communication in distributed systems. gRPC also uses an interface definition language (IDL) — protobuf — to define services, define methods, and messages as well as serializing structure data between servers and clients. Protobuf as a data serialization format is powerful and efficient — especially compared to text-based formats (like JSON). This makes a great choice for applications that require high performance and scalability.