Microservices and Web Application Security

Content:

➤ What is an authentication microservice
➤ What is API Gateway
➤ How certificates work
➤ How to store user passwords
➤ What is KMS (Key Management Service)
➤ What are solutions for protection against brute-force attacks
➤ What is mTLS
➤ What are popular encryption and hashing algorithms

➤ What is an authentication microservice

Authentication microservice:

• verifies who you are (authentication)
• decides what you can do (authorization)
• issues and validates access tokens (JWT and others)
• often works as Identity Provider (IdP) or part of API Gateway

Popular solutions

Keycloak (open-source, from Red Hat)

• Ready-made authorization server with its own admin panel and users.
• Supports OpenID Connect, OAuth2, SAML
• Issues JWT, manages sessions
• Has UI for users and admins
• Supports MFA, LDAP, Google Login, etc.
• Often used as SSO and central authorization service

Used as:

• /auth service
• Connects to frontend and backend
• Validates tokens through middleware or API Gateway

Auth0 (cloud, commercial)

• Ready-made cloud solution for authentication and authorization.
• Easy integration via SDK
• Supports social logins, MFA, RBAC
• Issues JWT tokens
• Suitable for SaaS, mobile and SPA
• Pros: fast, UI ready
• Cons: paid, depends on internet

OPA (Open Policy Agent) + Keto

• For policy-based authorization (ABAC) — who, what, under what conditions.
• OPA = rules engine (Rego language)
• Keto = open-source analog of Google Zanzibar (ACL storage)
• Allows checking: “Can user X do Y with resource Z?”
• Used together with other services
• OPA — extracts business rules from code

ORY Stack (Hydra, Kratos, Keto, Oathkeeper)

• Open-source authorization platform
• Hydra — OAuth2 / OIDC server (protocols only)
• Kratos — user management (login, registration, email)
• Keto — policy storage (RBAC/ABAC)
• Oathkeeper — API Gateway with authorization
• Flexible, powerful, but requires configuration
• Ideal for microservices architecture

▲To the list of questions▲

▲To the list of questions▲

➤ What is API Gateway

API Gateway is a single entry point to all microservices.
It receives requests from clients and:

• redirects them to the appropriate microservice (routing)
• validates authorization (e.g., JWT)
• performs rate-limiting, logging, CORS, etc.
• Client only communicates with Gateway
• Gateway hides internal structure
• It can add, remove, rename headers, validate tokens, etc.

[Client] → [API Gateway] ─→ [Microservice A]
                        └→ [Microservice B]
                        └→ [Auth Service]

Popular solutions

NGINX

• Works as reverse proxy
• Can add JWT validation (via Lua, njs, etc.)
• Very fast, simple to configure
• Good for low-level configuration (directly via config)

Kong

• Built on NGINX
• Plugin architecture (authorization, limits, loggers)
• Has UI, REST API, CLI
• Supports JWT, OAuth2, rate-limit, CORS, OpenID, gRPC, etc.

Traefik

Easy to use, especially with Docker/Kubernetes
Automatic service discovery (K8s ingress, Docker labels)
Supports TLS, Let’s Encrypt, JWT, middlewares

Envoy

Powerful proxy from Lyft
Used in Istio, gRPC, AWS App Mesh
Service mesh support
High performance and flexibility

AWS API Gateway (cloud)

Fully managed service from AWS
Integration with Lambda, IAM, Cognito, CloudWatch
Supports REST, WebSocket, HTTP APIs

▲To the list of questions▲

➤ How certificates work

A certificate is an identity document for computers and servers.
It confirms that the server is who it claims to be and contains its public key.

A certificate is a file in .crt, .pem, .cer, .der format, etc. It contains:

When opening a website, the browser:
Receives the server’s certificate
Checks if it’s signed by a trusted authority (CA)
— for example, Let’s Encrypt, DigiCert, Sectigo, etc.
Uses the public key from the certificate to:
verify the server’s authenticity
create a secret key that will be used to encrypt all traffic
Further data exchange goes through an encrypted channel (TLS)

Where certificates are used

• HTTPS on websites
• gRPC between microservices
• mTLS (mutual authentication of client and server)
• OAuth2 / OpenID (token signing via RSA/ECDSA)
• Kubernetes (kube-apiserver, kubelet, etcd)
• VPN (WireGuard, OpenVPN)

What types of certificates exist

By purpose:

By structure:

▲To the list of questions▲

➤ How to store user passwords

What not to do

• store password in plain text
• encrypt passwords “so they can be decrypted”
• use fast hashes (MD5, SHA-1, pure SHA-256)

How to store passwords

1. Hash passwords, don’t encrypt them
   • Take the password and pass it through a special slow function (KDF).
   • It makes password guessing very expensive.
   • All checks are done in one auth service, not in each microservice.
   • Microservices work only with tokens, not passwords.
2. Use KDF (key derivation functions for passwords)
   • Argon2id (best modern option, recommended by OWASP).
   • If not available — bcrypt or scrypt.
   • PBKDF2 can only be used for compatibility/government standards.
   • Generate a unique salt for each password.
3. Add salt
   • Unique random string for each user.
   • Stored together with the hash (this is normal).
   • Makes it so that two identical passwords from different people will have different hashes.
4. Can add pepper
   • This is a shared secret.
   • It’s not stored in the database.
   • If the database leaked but pepper didn’t — hashes are useless.
   • Store pepper separately (e.g., in KMS or Vault).
5. Store result in format with parameters
   For example, a string for bcrypt:

$2a$12$C6UzMDM.H6dfI/f/IKcEe.7WxoQ5y0CEajliV0z3yFNBPJzXeS.CW

It contains:

• algorithm (2a)
• complexity (12)
• salt
• the hash itself

Where to store passwords

• In a centralized authorization service (e.g., Keycloak, AWS Secrets Manager, custom Auth service).
• Other microservices don’t know passwords, they check tokens (JWT).
• This reduces the risk of leakage: only one service works with passwords.

Algorithm for authentication

1. User sends login + password to authorization service.
2. Service:
   • finds hash and salt in database
   • hashes the sent password with the same algorithm
   • compares with stored value (constant-time comparison)
3. If matches → JWT token is issued.
4. Other microservices only check the token, not passwords.

▲To the list of questions▲

➤ What is KMS (Key Management Service)

A service that manages encryption keys.
Its task: keys don’t lie in your code or database, but are stored in a secure place.
You don’t retrieve the key, you just tell KMS:

• “Encrypt this”
• “Decrypt this”
• “Sign this”

The key never leaves the storage.

How it works step by step

1. Creating master key

• A master key is created in KMS.
• This can be symmetric (AES) or asymmetric (RSA/ECC).
• This key cannot be downloaded, it always remains inside KMS.

2. Encrypting data

• You don’t encrypt large files themselves in KMS (it’s expensive and slow).
• Instead:
  1. KMS generates data key (temporary key for encryption).
  2. Data key is used in your application to encrypt data (e.g., AES-256).
  3. The data key itself is stored in your database, but encrypted (via KMS master key).

3. Decrypting data

• When you need to read data:
  1. You send the encrypted data key to KMS.
  2. KMS decrypts it and returns the decrypted data key.
  3. You use this data key to decrypt data locally.

Thus, KMS never sees your data — only keys.

Why this is secure

• Keys are stored in secure storage (HSM — hardware for cryptography).
• You don’t manage keys manually, KMS manages them.
• All actions (who, when encrypted/decrypted) are logged.
• You can set policy: “this key can only be used by service A”.
• You can do key rotation (new version every N days).

Where it’s used

• AWS KMS (Amazon)
• Google Cloud KMS
• Azure Key Vault (KMS part)
• HashiCorp Vault (self-hosted alternative)

▲To the list of questions▲

➤ What are solutions for protection against brute-force attacks

To protect microservices and API from brute-force attacks (password guessing, token guessing, login guessing, etc.), standardized solutions are used, both at the code level and at the infrastructure level (API Gateway, firewall, reverse proxy, etc.). Below is a systematic overview.

▲To the list of questions▲

➤ What is mTLS

mTLS = Mutual TLS, or “mutual TLS”.

Regular TLS (HTTPS) works like this:

• Client (browser, service) verifies server’s certificate to make sure it’s the right site/service.
• Server doesn’t verify client, it’s enough that client knows password/token.

In mTLS verification is mutual:

• Server presents its certificate to client.
• Client also presents its certificate to server.
• Both verify each other and ensure they’re communicating with a trusted party.

How it works step by step

1. Client connects to server and starts TLS handshake.
2. Server sends its certificate → client verifies it (CA signature, validity period, CN/SAN).
3. Server in response requests client’s certificate.
4. Client sends its certificate → server verifies it against trusted CA.
5. If both certificates are valid → secure connection is established.

Where mTLS is used

• Between microservices — so one service knows for sure that it’s being accessed by a trusted service, not an attacker.
• In B2B APIs — when companies exchange data and need to trust not only password/token, but also device/service certificate.
• In IoT — devices authenticate via certificates.
• In banking systems — mandatory requirement for channel protection.

Benefits of mTLS

• Mutual authentication (both server and client are verified).
• Keys are never transmitted, only confirmed via certificates.
• Convenient for “machine-to-machine” scenarios (microservices, API, IoT).
• Can replace passwords/tokens with certificates (or use together).

▲To the list of questions▲

➤ What are popular encryption and hashing algorithms

Encryption algorithms

Symmetric (one key for encryption and decryption)

• AES (Advanced Encryption Standard) — most popular, de facto standard
  • Modes: AES-GCM (often in TLS), AES-CBC, AES-CTR
  • Key length: 128 / 192 / 256 bits
• ChaCha20-Poly1305 — modern algorithm, alternative to AES
  • Faster on mobile and ARM
  • Used in TLS 1.3, WireGuard, Google services

Asymmetric (different keys: public and private)

• RSA — classic, widely used for TLS, signatures, key exchange
  • Reliability depends on key length (2048+ bits)
• Elliptic Curve Cryptography (ECC) — more modern and lightweight
  • ECDSA (digital signature)
  • ECDH / ECDHE (key exchange, used in TLS 1.3)
  • Ed25519, Ed448 (signatures, fast and secure)

Hashing algorithms

General (for data)

• SHA-2 (SHA-256, SHA-512) — standard in most systems
• SHA-3 (Keccak) — newer standard from NIST
• BLAKE2 / BLAKE3 — fast, modern alternative to SHA

For password storage (special KDF)

• Argon2id — modern winner of Password Hashing Competition, best option now
• bcrypt — old, but still widely used
• scrypt — better than bcrypt, but less used
• PBKDF2 — standard, but considered outdated (used for compatibility, FIPS)

Usage

• For data encryption: AES-GCM or ChaCha20-Poly1305
• For key exchange: ECDHE (in TLS 1.3)
• For signatures: ECDSA or Ed25519
• For file hashing: SHA-256 or BLAKE3
• For passwords: Argon2id (best choice), or bcrypt/scrypt

▲To the list of questions▲

Copyright: Roman Kryvolapov