{"id":11647,"date":"2025-02-03T17:55:47","date_gmt":"2025-02-03T16:55:47","guid":{"rendered":"https:\/\/www.basyskom.de\/?p=11647"},"modified":"2025-02-06T08:05:31","modified_gmt":"2025-02-06T07:05:31","slug":"setting-up-flutter-and-grpc-with-tls-and-token-based-authentication","status":"publish","type":"post","link":"https:\/\/www.basyskom.de\/en\/setting-up-flutter-and-grpc-with-tls-and-token-based-authentication\/","title":{"rendered":"Setting up Flutter and gRPC with TLS and token-based authentication"},"content":{"rendered":"
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Introduction<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In our recent article “State of Flutter on Embedded Linux” (see the\u00a0blog post<\/a>), we described the state and advantages of using Flutter on embedded Linux systems. In a follow-up article (see the blog post<\/a>), we presented some architectural considerations and concrete ideas on how a respective system architecture could look. One possible building block of the architecture is gRPC, which can be used for communication between the client and the backend (see\u00a0gRPC project website<\/a>). This enables a clean and strict separation of concerns. The HMI created with Flutter will run on mobile, desktop and embedded platforms.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In the context of the architecture described in the blog post, this article deals with the topic of security, which in most cases must be taken into account when communicating via networks. With gRPC you get a free (Apache License 2.0), high-performance and language-independent RPC framework that ensures the confidentiality, integrity and authenticity of the communicated data on the basis of HTTP\/2 and TLS.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In this article, we use a minimal example to show how these technologies can be combined to have a platform-independent Flutter app communicating securely with a backend running on an embedded system via gRPC.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

gRPC Support<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tA basic requirement for the presented approach is that the language used for the backend supports gRPC. \t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

As known from other RPC frameworks, gRPC comes with a compiler that transforms abstract interface definitions to code for the target language. For example, if you use C++ for the backend, the compiler provides you with C++ code for the client stubs, server skeletons and message types. As a basis for communication (locally or via networks), gRPC uses the project Protocol Buffers (“Protobuf”; see project website<\/a>), which comes with Protocol Buffers Compiler (“protoc”). Protobuf interface definitions are described in an abstract language in .proto<\/code> files. Along with a respective language plugin, the compiler uses the .proto<\/code> files to generate the code in the target language. So gRPC support means there is a plugin for protoc and a library for generic gRPC functionality which is linked with your server application.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The range of supported languages is quite extensive (see gRPC languages<\/a>). In addition, there are unofficial projects that are not listed here, such as tonic for rust (see project website<\/a>).<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In our example we use the official Dart package (see package website<\/a>) for both client and server as well as the official Dart plugin for protoc (see plugin website<\/a>) to generate the code. All components at this point are developed and (at the time of writing) actively maintained by\u00a0Google.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In real projects, other languages such as C++ are more likely to be used for the backend, which can be more easily connected to existing libraries, interfaces and middleware on the target. But as described in the previous blog post, for network facing services the use of memory-safe languages should be considered to avoid security issues caused by widespread memory-management errors like buffer overflows and the like.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Basic Idea<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The approach is very well established and well known from web technologies, where REST APIs, HTTP, TLS and access tokens are combined to implement secure communication between client and server. The rough procedure is:<\/p>