Forem: Vinicius Lopes

Load Balancing gRPC traffic with Istio

Vinicius Lopes — Mon, 17 Feb 2025 03:46:42 +0000

gRPC has gained a lot of popularity for building microservices. Because it is based on persistent HTTP/2 connections, it offers advantages over regular HTTP calls, such as multiplexing requests over a single connection. However, this protocol’s load balancing may not work out of the box in the Kubernetes environment.

⚠️ Houston we have a problem

When working with tens of millions of messages whose traffic needs to be as quick as possible in real-time, indicators such as SLA (Service Level Agreement) become a major concern. And, as the volume grows, performance degrades, requiring more infrastructure scalability and, in turn, a smaller profit margin. One strategy to optimize the internal network and avoid spending on resources would be to replace all HTTP 1.1 connections between microservices with a single gRPC connection.

gRPC

gRPC is a remote procedure call framework created by Google based on HTTP/2. It can set an interface and serialize data through a Protocol Buffer, a binary format less heavy than the PLAIN TEXT format of HTTP 1.1. With gRPC, you set the methods and the types by creating files .proto. These files can be used to automatically generate the client and the server code for a lot of languages. Additionally, as mentioned, it multiplexes requests into a single connection, which creates less network overhead and speeds up communication.

Why do the L4 proxies struggle when operating with gRPC?

The above diagram suggests a common use case for traffic balancing. The green pod sees the SVC, which sees the other blue pods. This should be enough to do a simple round-robin when we are talking about conventional HTTP. But here we are talking about HTTP/2, which establishes a long-lived connection, through which all requests must pass to reach their destination. Load balances that operate at layer four of the OSI model (L4) only decide the destination at the beginning of the connection, all subsequent requests under this connection will go to the same server, which leads to poor load distribution. L4 proxies handle connections, not requests. They have no visibility of what happens inside the connection.

How do we operate over the L7 layer?

Proxies operating at this layer have visibility into the packet content and can make different decisions regarding the delivery destination. This is where Istio comes in. Istio can provide a service mesh that deploys proxies as sidecar containers alongside the application container. Instead of a centralized entry point, the sidecar interacts with the Istio control plane, which in turn interacts directly with the Kubernetes API to retrieve the destination endpoints. In this way, the sidecar establishes a continuous and direct connection to all available endpoints, and then performs routing based on the rules that are defined.

🌐 Istio: The Service Mesh

What is it? Istio is a service mesh. And to understand what this means, we need to understand what a service mesh is.

A service mesh is a widely used solution to manage communication between microservices individually. It solves problems such as poor load balancing by operating at the application layer, and also adds retries in case of communication failure, traffic metrics, and security.

Using a sidecar, all these responsibilities are abstracted and the application only needs to worry about the logical layer in its implementation. This is done through the Istio Control Plane, which injects a sidecar proxy container into the pod along with the application. The applications now communicate with each other through these proxies. This network layer is composed of: a control plane and proxies, that is the service mesh.

🛠️ Hands-On

In a local environment, for demonstration purposes, I am using MicroK8s, maintained by Canonical. In production environments, add-ons can be installed by tools such as Helm. In MicroK8s, add-ons can be enabled directly from the command line.

First, let's enable third party and community maintained add-ons with the following command:

microk8s enable community

And then, enable Istio by running:

microk8s enable istio

This should add:

✔ Istio core installed
✔ Istiod installed
✔ Egress gateways installed
✔ Ingress gateways installed
✔ Installation complete

Now let's set up a namespace for the lab. It will be named serivce-mesh-lab.

microk8s kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: service-mesh-lab
  labels:
    istio-injection: enabled
EOF

ℹ️ Notice that there is a label called istio-injection with the value set to enabled. This label is how the Istio Control Plane knows that it will need to inject a sidecar proxy into the pods under this namespace.

Building the gRPC application

I have made available a repository that performs message transmission between client and server via gRPC in a simple way. Clone the repository using the following command:

git@github.com:visepol/grpc-relay.git

Now it is necessary to build the images.

To build the client, run:

docker build -t grpc-client:local --build-arg APP_MODE=client .

To build the server run:

docker build -t grpc-server:local --build-arg APP_MODE=server .

Adding an image to the local registry

Kubernetes is not aware of the newly built images. We can export the built image from the local Docker daemon and import it into the MicroK8s local registry like this:

docker save grpc-client:local > grpc-client.tar

docker save grpc-server:local > grpc-server.tar

and then import with:

microk8s ctr image import grpc-client.tar

microk8s ctr image import grpc-server.tar

Finally, we can deploy the applications for analysis in two namespaces.

The first will be in the default namespace, where we will use the default L4 proxy to distribute messages.

microk8s kubectl apply -f ./kubernetes -n default

The second will be in the namespace we created, service-mesh-lab, where the proxies will be injected as a sidecar to operate in L7.

microk8s kubectl apply -f ./kubernetes -n service-mesh-lab

🎥 Demo

A look at the Code

The code below shows the contents of the gRPC Server. Note that on line 6 a UUID is generated to identify the message receiver in the gRPC Client. Next, the IExampleServer interface is implemented on line 12, ensuring adherence to the contract defined in .proto. The service is then added to the server on line 33, making the methods available to the client. On line 40 I use .createInsecure() to make the Demo easier. In production environments, the use of TLS is ideal.

The code (on Github):

import * as grpc from '@grpc/grpc-js'
import { IExampleServer, ExampleService } from './generated/example_grpc_pb'
import { DataResponse } from './generated/example_pb'
import { randomUUID } from 'crypto'

const uuid = randomUUID()

/**
 * Implements the ExampleService defined in the proto file.
 * @type {IExampleServer}
 */
const exampleService: IExampleServer = {
  /**
   * Handles the sendData RPC call.
   * @param {grpc.ServerUnaryCall<DataRequest, DataResponse>} call - The call object containing the request.
   * @param {grpc.sendUnaryData<DataResponse>} callback - The callback to send the response.
   */
  sendData: (call, callback) => {
    console.log('Received message:', call.request.getMessage())
    const response = new DataResponse()
    response.setReply(
      `Hello, I'm ${uuid}. You sent: ${call.request.getMessage()}`,
    )
    callback(null, response)
  },
}

const server = new grpc.Server()

/**
 * Adds the ExampleService to the gRPC server.
 */
server.addService(ExampleService, exampleService)

/**
 * Binds the server to the specified address and starts it.
 */
server.bindAsync(
  '0.0.0.0:50051',
  grpc.ServerCredentials.createInsecure(),
  () => {
    console.log(
      "Server's up—smooth as a race car! 🏎️💨",
    )
  },
)

The code below shows the content of the gRPC Client. In line 10 I use the K8s metadata to set the SVC that I should point to and in line 11 I avoid the use of TLS again. The request is instantiated from the model generated by ProtoBuff in line 18. And finally, in line 23, I define the continuous sending of messages within a 10-second window.

The code (on Github):

import * as grpc from '@grpc/grpc-js'
import { ExampleClient } from './generated/example_grpc_pb'
import { DataRequest } from './generated/example_pb'

/**
 * Creates a new gRPC client for the ExampleService.
 * @type {ExampleClient}
 */
const client: ExampleClient = new ExampleClient(
  `grpc-service.${process.env.K8S_NAMESPACE}.svc.cluster.local:50051`,
  grpc.credentials.createInsecure(),
)

/**
 * Creates a new DataRequest object.
 * @type {DataRequest}
 */
const request: DataRequest = new DataRequest()

/**
 * Sends a message to the gRPC server every 10 seconds.
 */
setInterval(() => {
  request.setMessage('Hello, gRPC!')
  client.sendData(request, (error, response) => {
    if (error) {
      console.error(error)
      return
    }

    console.log(`Server reply:`, response.getReply())
  })
}, 10 * 1000)

Results

Let's analyze the communication established in the default namespace:

✳️ Each pod contains only one container, indicated by the single green square in the containers column. This indicates that the application is running stand-alone.

✳️ The client gRPC received messages only from the server with UUID efd7bef0-0148-4296-b243-3262c7d82fd1. Once the connection was established all responses were issued by the same gRPC server.

Let's analyze the communication established in the service-mesh-lab namespace:

✳️ There were three containers inside each pod. An ephemeral container for sidecar injection, a container that remains alive and running which is the injected proxy, and another standing container which is the application itself.

✳️ The Server reply that is logged by the gRPC client indicates different UUIDs. This means that more than one gRPC server is responding to the same client.

🚦 Advanced Routing & Balancing

Istio allows you to configure load balancing and routing through DestinationRules and VirtualServices. Configurations are defined through YAML manifests and you can choose between different load balancing algorithms, such as round-robin or least-conn. As for routing, Istio allows you to direct traffic based on headers, paths, and other criteria to different subsets of a service. Explore more about these and other features by browsing the official documentation.

✅ Final Considerations

gRPC is a great solution for improving the speed of your internal network, but to get the most out of the solution, you need to provide an environment that meets the requirements. Istio is a great way to make your network more robust, providing a service mesh standard with proxies acting on layer seven of the OSI model. This ensures not only the proper balancing of packet traffic in persistent connections but also promotes security with internal encryption, traffic metrics, and more routing strategies.

References:

https://en.wikipedia.org/wiki/OSI_model
https://grpc.io/blog/grpc-load-balancing/
https://istio.io/latest/docs/overview/what-is-istio/
https://istio.io/latest/docs/setup/platform-setup/microk8s/
https://istio.io/latest/docs/reference/config/networking/
https://istio.io/latest/docs/reference/config/networking/destination-rule/
https://istio.io/latest/docs/reference/config/networking/virtual-service/
https://microk8s.io/docs/addons
https://microk8s.io/docs/registry-images

OAuth2, JWT, and JWKS: Using Amazon Cognito as IdP

Vinicius Lopes — Wed, 27 Nov 2024 00:16:01 +0000

The amount of interconnected applications on the web has grown significantly over the last decade. With it, the number of threats aimed at fraud or other malicious actions has also increased. OAuth, now in version 2.0, emerges as a protocol to define how these applications should communicate with each other without compromising the security of the transmitted information and ensuring its authenticity.

This article will discuss how this protocol works and how we can implement it modern and securely using JWT tokens and validating with JWKS. The content here can be used as a guide for beginners who have yet to become familiar with the mentioned concepts.

OAuth 2.0

OAuth2 is an authorization protocol that allows third-party applications to access a user's resources without directly exposing their credentials. Instead, OAuth2 uses access tokens, which are limited in scope and time.

✨ OAuth2 defines four actors

✳️ Resource Owner: This entity has access rights to the resource, which grants the credentials. It is typically classified as a user.

✳️ Resource Server: This is the API exposed on the web that contains the user's data. Access to this data is granted through a token issued by the following actor, the Authorization Server.

✳️ Authorization Server: Responsible for authentication, it is the one who receives the user's credentials and returns an access token. The tokens issued can be rich, containing information about the Resource Owner, or opaque, provided only as a signed key. This token grants access to the Resource Server.

✳️ Client: This is the application that effectively interacts with the Resource Owner, such as a browser or another HTTP client.

This flow demonstrates, in a simplified way, the relationship between the actors involved.

Bearer Token & JWT (JSON Web Token):
The Language of Tokens

Bearer Token

In practical terms, a Bearer Token is the access token issued by the Authorization Server to be sent to the APIs via Header, granting access to the content. The most widely adopted implementation format is JWT. However, the OAuth 2.0 protocol does not mention JWT as a standard. RFC 6750 only specifies the nature of the token as an authentication string but is broad regarding formats and structures.

JWT

It is a token standard whose format allows it to be transmitted between two parties. It not only authorizes access to resources but also carries other relevant information through claims. It has a set of rules, both for issuance and validation, that must be followed to comply with the format. This format allows information to be transmitted securely over an insecure channel.

A JWT token follows this format:

🔴eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
🔵eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
🟢SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

This sequence is composed of three segments:
🔴Header, 🔵Payload, and 🟢Signature.

Header

It includes a small JSON that stores data about the token type and the encryption algorithm used.

Payload

Also in JSON, it carries the user's Claims. Claims contain data that the API uses to verify a user's access rights to the resource and, at times, share information with other services and applications.

Signature

The signature is formed by the Header and Payload encoded in Base64. Then, a password is combined using the encryption algorithm specified in the Header, thus forming the final key.

The signature protects the token against malicious changes, ensuring the authenticity of the information being transmitted. Attacks like man-in-the-middle are unable to forge the Claims content, as they do not have the password to generate a new signature.

JWKS (JSON Web Key Set):
Public Key Management

A JWKS is a set of public keys made available through an endpoint of the token issuer itself to validate JWT signatures. When using asymmetric cryptography, meaning a key pair to sign the token instead of a unique secret (symmetric cryptography), only the Authorization Server has access to the private key, and the public keys are shared so that applications can validate whether the token was indeed issued by the Authorization Server.

Take a look at an example:

{
    "keys": [
        {
            "kty": "RSA",
            "e": "AQAB",
            "use": "sig",
            "kid": "ca761cd3-8092-46be-926b-ef28465ff942",
            "n": "oXAP360uf_9_KXTCk6BiQOgwQJlqoycCbsukFtoUCmn57jM-9n2uqBBPT_8VnTIaYr4h8zxMy8HRkdX35HRmZANoqekhH03hhMc69mK4yEYZwBNyV9SteXrF5hfj4SWsK0t3CZ_G_U303XLj7ak5m-4w1UXCmvBERR_SwXjLOKwAAFlOQS_0sAB9yzvJkvsuvqd4lA3-vFFF_ZVbTHuJAznqB_avwCbCHJWfiWln2PN7LsieX08tE13bPP1TVEFid9mcUz5dwz0J9QKTYCd90fkyzqanzG638SFoyL84ddmD_9pef5x03oMWEU9-dxEI6PFfWEQmXN1eg7GfJI6bxQ"
        }
    ]
}

One of the fields is kid, which is a key identifier, also present in the JWT header. It is through this identifier that we know which key in the JWKS set will be used to validate the signature of our token.

AWS Cognito: Identity Provider

Cognito is an AWS service that manages identity and access. It acts as a user directory, capable of storing and validating data, authenticating access, and securely providing identity. We can store fields such as email, name, phone, birthdate, nickname, gender, or any other information through custom attributes. In addition, Cogito offers multiple ways to log in to the same resource.

Demo with JWKS

Let's break down a TypeScript project that implements the OAuth 2.0 solution using Cognito as the identity provider. The goal here will be to retrieve an access token using the credentials provided by an HTTP Client and validate the token's signature against a JWKS keychain.

User Pool Creation

First, we need to configure our provider. Access the AWS Management Console and search for Cognito. Navigate to the service and look for the Create user pool option. There are a total of 6 steps, the last one being a review of the options selected before creating the user pool. I will display my final step, highlighting the selected options and emphasizing what is relevant to the demonstration.

Sign-in experience:

User name is enabled as a login option.
Email is enabled as a login option.

Security requirements:

I used Cognito's default policy for user password definition.
MFA is disabled.
Self-service account recovery option is disabled.

Sign-up experience:

Self-registration is disabled, users will be created directly in the console for demo purposes.
None of the default attributes are mandatory.

Message delivery:

I am not using SES for sending emails.
I am not using SNS to send any type of notification.
I selected the option Send email with Cognito.

Integrate your app:

I added the following authentication flows: ALLOW_REFRESH_TOKEN_AUTH, ALLOW_USER_SRP_AUTH and ALLOW_USER_PASSWORD_AUTH
My User pool name will be byte-terrier-idp
My App type will be Public client
And finally, My App client name will be aws-cognito-w-jwks

With everything set up, access: cognito -> user pools -> “the-pool-created”
Now, you should see a screen similar to this:

Take note of two items from the screen, as these values will be used later in the demo.

User pool ID, It is the identifier of your pool.
Token signing key URL, this is the JWKS endpoint where the set of public keys for validation will be available.

User Creation

Still in the created pool, look for the Create user option. A new page should appear. Once again, I have listed the options that should be selected.

The user will be able to log in with either the Username or the Email.
The user will not receive any type of invitation.
The username will be Meyer (it's the name of my dog).
The email will be meyer@boston.com
A temporary password will be created.

Click on Create user. A new user will be created but with the status Force change password. Since the goal here is only to perform a demo and not an end-to-end implementation, I will force the user's password through CLI. I am assuming that your AWS credentials are correctly configured in the environment.

Check at: ~/.aws/credentials
If they are not, here’s how to set them up: Configuring AWS CLI Credentials

Run the following command, making the necessary replacements.

aws cognito-idp admin-set-user-password --user-pool-id '<your-user-pool-id>' --username '<your-username>' --password '<your-new-password>' --permanent

Example:

aws cognito-idp admin-set-user-password --user-pool-id 'us-east-1_ErtWYLogU' --username 'meyer' --password 't!)l5T$C825l' --permanent

This should change the user's status to Confirmed.

App Client

Finally, go to: App integration -> App client list
...and find the app's Client. This ID will be needed for integration between the AWS SDK and Cognito.

A look at the code

I created a simple HTTP API in TypeScript for us to dissect and analyze how the integration with Cognito works using the AWS SDK. For better tracking, you might want to clone the repository to your machine, which can be done using the following command

git clone git@github.com:vynnux/aws-cognito-w-jwks.git

Here is the directory structure:

/aws-cognito-w-jwks
├── .env.example
├── .gitignore
├── package-lock.json
├── package.json
├── request.http
└── src
    ├── app.ts
    ├── server.ts
    ├── http
    │ ├── _routes.ts
    │ ├── authenticate.controller.ts
    │ └── verify-jwt.controller.ts
    └── lib
        ├── cognito.ts
        └── jwks.ts

Running the server

To start the project we must define the environment variables. Create a new file named .env based on .env.example and set the values according to what is shown in your user pool.

Here is a description of each one for better understanding:

COGNITO_CLIENT_ID - This is the Application's Client ID, which can be found in the App client list. It should be unique for each application, for better management.
AWS_REGION - This is the region where the user pool that was created is located.
JWKS_URI - This is the JWKS endpoint for querying public keys. It appears in the main dashboard of the User Pool.
DEBUG (optional) - When set to the value - jwks, it increases verbosity for the jwks-rsa dependency, which we use to validate the token signature.

Moving on… Now, we need to install the project dependencies. Run npm to download the packages.

npm i

Once completed, we are ready to start our server, which will listen on port 3000. Run...

npm start

If everything goes well, your output should be:

🍃 HTTTP Server Running.

Analysis

There’s no reason to cover the entire code in this article; in short, it’s an API built with Fastify. Both controllers perform some processing and validation before actually executing their actions. Feel free to take a look at the other files, but here, we will focus on cognito.ts and jwks.ts under the lib folder.

cognito.ts

The /authenticate route is responsible for generating the JWT token. This is where the user credentials are passed via the POST method. If we open the request.http file, located at the root of the project, we will see…

POST http://localhost:3000/authenticate HTTP/1.1
content-type: application/json

{
"username": "meyer",
"password": "t!)l5T$C825l"
}

This request should return the following response:

In username field, we must pass the username that was registered. The interesting thing here is that, as mentioned previously, Cognito supports several login methods, and one of the methods we enabled was via email. Therefore, we could log in as the same user using a different credential, in this case, meyer@boston.com.

As for the password, we must pass the permanent password that we set for the user, the one we defined using the AWS CLI.

The code (on Github):

import {
  CognitoIdentityProviderClient,
  InitiateAuthCommand,
  InitiateAuthCommandInput,
} from '@aws-sdk/client-cognito-identity-provider'

const AWS_REGION = process.env.AWS_REGION || 'us-east-1'
const COGNITO_CLIENT_ID = process.env.COGNITO_CLIENT_ID || ''

const cognitoClient = new CognitoIdentityProviderClient({
  region: AWS_REGION,
})

/**
 * Get a JWT token from Cognito using the USER_PASSWORD_AUTH flow
 * @param {string} username - The login credential of the user
 * @param {string} password - The password credential of the user
 * @returns {Promise<string | undefined>} - The JWT Token
 */
export async function getJwtToken(
  username: string,
  password: string,
): Promise<string | undefined> {
  const params: InitiateAuthCommandInput = {
    AuthFlow: 'USER_PASSWORD_AUTH',
    ClientId: COGNITO_CLIENT_ID,
    AuthParameters: {
      USERNAME: username,
      PASSWORD: password,
    },
  }

  const command = new InitiateAuthCommand(params)
  const response = await cognitoClient.send(command)

  return response.AuthenticationResult?.IdToken
}

When we make the request, the data is delivered to the getJwtToken function (line 20), which in turn initializes an AWS Client to interact with our IdP (Cognito). We tell the Client that the authentication flow to be used will be USER_PASSWORD_AUTH (line 25), meaning authentication via username and password. If the authentication is successful, the token is returned. Otherwise, the controller will set the HTTP status 401, which is unauthorized access.

jwks.ts

The /verify-jwt route (GET) is responsible for validating the signature of our token. We must add a header - Authorization - with the value Bearer + jwt. The controller will sanitize the token, removing the Bearer prefix before invoking the validateTokenSignature method in the jwks.ts file.

The full request looks like this:

GET http://localhost:3000/verify-jwt HTTP/1.1
content-type: application/json

Authorization: Bearer eyJra...

The code (on Github):

import jwt from 'jsonwebtoken'
import jwksClient from 'jwks-rsa'

const JWKS_URI = process.env.JWKS_URI || ''

export class JWKSValidationError extends Error {
  constructor() {
    super('JWKSValidationError')
  }
}

/**
 * Validate the signature of a JWT Token against the JWKS URI
 * @param {string} token - The JWT Token to verify
 * @returns {Promise<void>} - Promise that resolves if the token is valid
 */
export async function validateTokenSignature(token: string): Promise<void> {
  const client = jwksClient({
    jwksUri: JWKS_URI,
  })

  const header = jwt.decode(token, {
    complete: true,
  })?.header
  if (!header) throw new JWKSValidationError()

  const signingKey = await client.getSigningKey(header.kid)
  if (!signingKey) throw new JWKSValidationError()

  await new Promise((resolve, reject) => {
    jwt.verify(
      token,
      signingKey.getPublicKey(),
      { algorithms: ['RS256'] },
      (err, decoded) => {
        if (err) reject(err)
        resolve(decoded)
      },
    )
  })
}

In jwks.ts, on line 18, a JWKS Client is created to fetch the JSON containing the collection of public keys. On line 22, we decode the token to extract its header and locate the kid, which is the key ID we need to match. On line 27, we search for the key in the set. Finally, on line 30, we create a promise and use jwt.verify to verify the signature of the keys. The key will be decrypted using the RS256 algorithm and its content must be exactly a base64 of the Header + Payload.

ℹ️ This is why every JWT starts with ey, it is the encoding of {", the beginning of a JSON structure in base64.

If something goes wrong, anything at all, an exception will be thrown, and the controller will reject access to the resource, not displaying the expected response — HTTP 200 OK.

Final Considerations

This article covered concepts that promote greater care and security for our user's data. We applied these concepts to one of AWS's services, Cognito, which offers several other strategies beyond the one discussed - such as MFA or SSO. These practices should help prevent malicious attacks and minimize the risk of fraud, as well as being an efficient way to ensure granular access control for your users.

For more information about Cognito, see the official documentation.

References:

https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html
https://jwt.io/introduction/
https://datatracker.ietf.org/doc/html/rfc6750
https://datatracker.ietf.org/doc/html/rfc6749
https://datatracker.ietf.org/doc/html/rfc7519

Forem: Vinicius Lopes

Load Balancing gRPC traffic with Istio

⚠️ Houston we have a problem

gRPC

Why do the L4 proxies struggle when operating with gRPC?

How do we operate over the L7 layer?

🌐 Istio: The Service Mesh

🛠️ Hands-On

Building the gRPC application

Adding an image to the local registry

🎥 Demo

A look at the Code

Results

🚦 Advanced Routing & Balancing

✅ Final Considerations

References:

OAuth2, JWT, and JWKS: Using Amazon Cognito as IdP

OAuth 2.0

Bearer Token & JWT (JSON Web Token): The Language of Tokens

Bearer Token

JWT

Header

Payload

Signature

JWKS (JSON Web Key Set): Public Key Management

AWS Cognito: Identity Provider

Demo with JWKS

User Pool Creation

Sign-in experience:

Security requirements:

Sign-up experience:

Message delivery:

Integrate your app:

User Creation

App Client

A look at the code

Running the server

Analysis

cognito.ts

jwks.ts

Final Considerations

References:

Bearer Token & JWT (JSON Web Token):
The Language of Tokens

JWKS (JSON Web Key Set):
Public Key Management