Security of Things (SoT) APIs and Microservices

Be secure by design, Hi everyone to make sure How I’m I, I am a developer of technology (Solutions, Integration, Architecture)

let start talk our title (SoT)

What are you are knowing about security, and what is an approach before starting a design or development, and why the security part is very important,

Security of Things Content, I’ll answer all of the questions confuse,

I will explain what I have knowledge about security.

OpenID Connect

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.

Why and When?

When an Authorization Server supports OIDC, it is sometimes called an identity provider, since it provides information about the Resource Owner back to the Client. OpenID Connect enables scenarios where one login can be used across multiple applications, also known as single sign-on (SSO)

Which mean the application trust the end-user with providers for example (Google, Twitter, Facebook) and so in, using this approach to authenticate and authorize by providers that mean I trust end-user but I don’t know who he is, we have a workaround to knowing the end-user by sent to provider with a background sharing information about the user to saving in your system.

Overview of the SSO process

The basic SSO process, stripped of most details, is fairly simple:

SITE A

1. The user wants to login on Site A
2. Site A sends an OpenID Connect Authorization Request
3. Curity authenticates the user
4. Curity establishes an SSO session
5. Curity responds with an ID token
6. Site A validates and uses the ID token to setup a local session

SITE B

1. The user accesses Site B
2. Site B sends an OpenID Connect Authorization Request
3. Curity finds and uses the existing SSO session
4. Curity sends a new ID token
5. Site B validates and uses the token to setup a local session

To more details and how to implement OIDC (SS0)

please find what I have posted before.

OpenID Connect with .NET Core 2.2 with Keycloak , Google and Twitter .

Also, here the Source Code, I developed before.

mohsenTalal/Security.OpenIdConnect

JWT (JSON Web Token)

JSON Web Tokens (JWT), pronounced “jot”, are a standard since the information they carry is transmitted via JSON.

JWT is popular for Authentication and Information Exchange. The server encodes data into a JSON Web Token and send it to the Client. The Client saves the JWT, then every Request from Client to protected routes or resources should be attached that JWT.

JSON Web Tokens work across different programming languages: JWTs work in .NET, Python, Node.js, Java, PHP, Ruby, Go, JavaScript, and Haskell. So you can see that these can be used in many different scenarios.

JWTs are self-contained: They will carry all the information necessary within itself. This means that a JWT will be able to transmit basic information about itself, a payload (usually user information), and a signature.

JWTs can be passed around easily: Since JWTs are self-contained, they are perfectly used inside an HTTP header when authenticating an API. You can also pass it through the URL

What does a JWT look like?

A JWT is easy to identify. It is three strings separated by.

Since there are 3 parts separated by a ., each section is created differently. We have the 3 parts which are:

• header
• payload
• signature

JWT

Header

The header carries 2 parts:

• declaring the type, which is JWT
• the hashing algorithm to use (HMAC SHA256 in this case)

Payload

The payload will carry the bulk of our JWT, also called the JWT Claims. This is where we will put the information that we want to transmit and other information about our token.

There are multiple claims that we can provide. This includes registered claim names, public claim names, and private claim names.

Registered Claims

Claims that are not mandatory whose names are reserved for us. These include:

• iss: The issuer of the token
• sub: The subject of the token
• aud: The audience of the token
• exp: This will probably be the registered claim most often used. This will define the expiration in NumericDate value. The expiration MUST be after the current date/time.
• nbf: Defines the time before which the JWT MUST NOT be accepted for processing
• iat: The time the JWT was issued. Can be used to determine the age of the JWT
• jti: Unique identifier for the JWT. Can be used to prevent the JWT from being replayed. This is helpful for a one time use token.

Public Claims

These are the claims that we create ourselves like user name, information, and other important information.

Private Claims

A producer and consumer may agree to use claim names that are private. These are subject to collision, so use them with caution.

Signature

The third and final part of our JSON Web Token is going to be the signature. This signature is made up of a hash of the following components:

• Header
• Payload
• Secret

OAuth 2.0

OAuth 2.0 is an open authorization protocol, which allows accessing the resources of the resource owner by enabling the client applications on HTTP services.

OAuth 1.0

OAuth 1.0 can be used for authorization of various applications or manual user access. The general way it works is providing an application with an access token (which represents a user’s permission for the client to access their data) for request authentication.

What’s the difference? OAuth 1.0 vs OAuth 2.0? And which version of OAuth is right for you?

You might expect the answer to this question to be “The latest, obviously.” But this is not necessarily the case. The changes that took place between OAuth 1.0 and OAuth 2.0 actually changed the nature of OAuth significantly enough that the two versions actually meet different needs, based on what you’re trying to accomplish

So how do I choose?

In many cases, it is no longer feasible to use OAuth 1.0 as a client-side implementer. for example, Google moved away from OAuth 1.0.

OAuth 2.0 is almost always the right choice today. If your desire is to use OAuth with proper cryptography, the trend is more and more to use OAuth 2.0 with cryptographic extensions.

OAuth 1.0

• Transport-independent. Security is not delegated to HTTPS/TLS.
• Founded in cryptography, especially digital signatures. Digital signatures are used to prove the integrity and authenticity of a message. Digital signatures can ensure that a certain message was sent from a specific source and that the message and signature were not tampered with in any way. A signed message is tied to its origin. It cannot be tampered with or copied to another source, but client-side implementations can be especially complex.
• Messages are each individually cryptographically signed. If a single message within the communication is constructed or signed improperly, the entire transaction will be invalidated
• Basic signature workflow.

1. Client application registers with the provider, such as Twitter.
2. Twitter provides the client with a “consumer secret” unique to that application.
3. The client app signs all OAuth requests to Twitter with its unique “consumer secret.”
4. If any of the OAuth request is malformed, missing data, or signed improperly, the request will be rejected.

OAuth 2.0

• Transport-dependent. Most security defenses are delegated to HTTPS/TLS. A typo, an improper TLS configuration, a failure to properly validate a certificate, or vulnerabilities in an underlying library can lead to a man-in-the-middle (MitM) attack, compromising all OAuth communications.
• Centered around bearer tokens. These are easy for integration but not great for security. Bearer tokens do not provide internal security mechanisms. They can be copied or stolen but are easier to implement.
• Much easier to work with. OAuth 2.0 is much more usable, but much more difficult to build securely.
• Much more flexible. OAuth 1.0 only handled web workflows, but OAuth 2.0 considers non-web clients as well.
• Better separation of duties. Handling resource requests and handling user authorization can be decoupled in OAuth 2.0.
• Basic signature workflow.

1. Client application registers with the provider, such as Twitter.
2. Twitter provides the client with a “client secret” unique to that application.
3. Client application includes “client secret” with every request.
4. If any of the OAuth request is malformed, missing data, or contains the wrong secret, the request will be rejected.

What is Identity and Access Management (IAM)?

Identity management is the process by which user identities are defined and managed in an enterprise environment. Specifically, identity management describes the process by which: User identities are provisioned and coordinated. Application provisioning is automated. User roles, privileges, and credentials are managed.

At the end of the day, IAM solutions help identify and mitigate security risks. You can use IAM to identify policy violations or remove inappropriate access privileges, without having to search through multiple distributed systems. You can also leverage IAM to ensure that security measures are in place to meet regulatory and audit requirements. the Benefits are Improved security, Information sharing, Ease of use, Productivity gains, and Reduced IT Costs.

To more details and how to development Identity Solution

here the Source Code, I developed before.

mohsenTalal/IdentityServer

What and Why Is a Service Mesh? and how to secure communication between microservice?

Securing service-to-service interaction over HTTP.
A service mesh can be defined as an infrastructure layer which handles the inter-service communication in a microservice architecture. Service mesh reduces the complexity associated with a microservice architecture and provides a lot of the functionalities like:

• Load balancing
• Service discovery
• Health checks
• Authentication
• Traffic management and routing
• Circuit breaking and failover policy
• Security
• Metrics and telemetry
• Fault injection

What and Why is Istio?

At a high level, Istio helps reduce the complexity of these deployments and eases the strain on your development teams. It is a completely open-source service mesh that layers transparently onto existing distributed applications. It is also a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system. Istio’s diverse feature set lets you successfully, and efficiently, run a distributed microservice architecture, and provides a uniform way to secure, connect, and monitor microservices.

Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality, which includes:

• Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
• Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
• A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
• Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
• Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.

outher beanifiet

The Core Features are Traffic management, Security, and Observability.

Let’s explain what is most important when design APIs and microservices!

An API Gateway is an API management tool that sits between a client and a collection of backend services. An API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.

API Gateway ≠ API Management

Although the terms API gateway and API management are sometimes used interchangeably, it is important to note that there is a difference.

An API gateway is a gatekeeper for access to APIs, securing and managing traffic between API consumers and the applications that expose those APIs. The API gateway typically handles authentication and authorization, request routing to backends, rate limiting to avoid overloading systems and protect against DDoS attacks, offloading SSL/TLS traffic to improve performance, and handling errors or exceptions.

In contrast, API management refers to the process of managing APIs across their full lifecycle, including defining and publishing them, monitoring their performance, and analyzing usage patterns to maximize business value.

Common API Gateway Deployment Patterns

Centralized, Edge Gateway

This is the most common API gateway pattern and follows a traditional application delivery controller (ADC) architecture. In this pattern, the gateway handles almost everything, including: SSL/TLS termination, Authentication, Authorization, Request routing
Rate limiting, Request/response manipulation, and Facade routing

Two-Tier Gateway

As services are slowly becoming smaller and more distributed, many organizations are moving towards a two‑tier (multi‑layer) gateway pattern that introduces a separation of roles for multiple gateways.

This approach utilizes a security gateway as the first layer to manage:

• SSL/TLS termination
• Authentication
• Centralized logging of connections and requests
• Tracing injection

A routing gateway acts as the second layer, handling:

• Authorization
• Service discovery
• Load balancing

Microgateway

A microgateway gateway pattern builds on the two‑tier approach by providing a dedicated gateway to individual DevOps teams, which not only helps them manage traffic between services (east‑west traffic) but lets them make changes without impacting other applications.

This pattern enables the following capabilities at the edge:

• SSL/TLS termination
• Routing
• Rate limiting

Organizations then add individual microgateways for each service that manage:

• Load balancing
• Service discovery
• Authentication per API

Per-Pod Gateways

The per‑pod gateway pattern modifies the microgateway pattern by embedding proxy gateways into individual pods or containers. The gateway manages ingress traffic to the pod, applies policies such as authentication and rate limiting, then passes the request to the local microservice.

The per‑pod gateway pattern does not perform any routing or load balancing, so it is often deployed in combination with one of the patterns above. Specifically, you might use the per‑pod gateway to perform some or all of the following capabilities:

• SSL/TLS termination for the application in the pod
• Tracing and metrics generation
• Authentication
• Rate limiting and queuing
• Error handling, including circuit breaker‑style error messages

Sidecar Gateways and Service Mesh

The sidecar gateway pattern deploys the gateway as an ingress and egress proxy alongside a microservice. This enables services to speak directly to each other, with the sidecar proxy handling and routing both inbound and outbound communication.

This pattern uses an edge gateway that manages:

• SSL/TLS termination
• Client authentication
• Centralized logging
• Tracing injection

Sidecar proxies are then used as the entry point to each service, providing:

• Outbound load balancing
• Service discovery integration
• Inter‑service authentication
• Authorization

In the end, I hope you got what I explained and please if you see any wrong let me know

Everything that is written is nothing new.

Thank you so much for reading my tutorial and I hope you got my point, By

— — — — — — — — — Mohsen Talal — — — — — — — — —