By the end of the lesson, you can explain what mTLS proves and what it does not, distinguish a service's identity from a user's authorization, and list the most important steps of checking a token.
Why is it needed?
Between services too, it must be checked who is calling, what they are authorised to do, and which resource they affect. The internal network is not automatically trustworthy: through misconfiguration, a compromised component or an accidentally public route, an unauthorised caller can also reach the service.
Encrypted connection and identity: TLS and mTLS
TLS (Transport Layer Security) provides an encrypted connection, and based on the server's certificate the client can check whom it is connecting to. According to RFC 8446 (TLS 1.3), a server that authenticates with a certificate may optionally request a certificate from the client as well. This is mTLS (mutual TLS): both parties prove their identity with a certificate. It can provide service or workload identity, but by itself it does not say what business operation the identified caller may perform.
Certificate management involves issuance, validity, renewal and the trust root. An expired or unknown certificate must not be "fixed" by switching off the check.
Service and user context
A call can be a pure service operation, or one performed on behalf of a user. The two must be distinguished: besides the service's own identity, the user's authorization and the tenant context may also be needed. A token issued for a public client should not automatically be forwarded to every internal service if they are not among the permitted audiences.
Checking a token (JWT)
If the context travels as a JWT (JSON Web Token), according to RFC 8725 (JWT Best Current Practices), among other things:
the library accepts only the algorithms specified by the caller; the algorithm and the key belong together;
the signing key must belong to the issuer (iss), and the value of sub must be compared with the application's known subjects;
if an issuer issues tokens to several audiences, the presence and match of aud (audience) must be checked;
kid and the URL fields specifying the key source (jku, x5u) can open the way to injection and SSRF, so they must be filtered;
the validation rules of JWTs for different purposes should be mutually exclusive (for example with the typ header).
Decoding the content of a token is not authentication.
Object-level authorization
The entry point (gateway) can authenticate and apply a preliminary access rule. The service, however, is the data owner: it can decide whether the caller may modify the given record. The essence of BOLA (Broken Object Level Authorization), at the top of the OWASP API Security Top 10, is that the attacker changes an object identifier in the request and reaches data they would have no right to. According to OWASP, it is not enough to compare the session's user with the identifier; in every function that accesses data from client input, it must be checked whether the logged-in user may perform the operation on the requested record.
flowchart LR
C["Client"] --> G["Gateway: authentication"]
G --> S["Service: caller and scope"]
S --> A["Record- and tenant-level authorization"]
A --> D[("Own data")]
The tenant identifier sent by the client must be compared with the trusted context. Caches, background work and event consumption must not lose this boundary: a cache or read model with faulty authorization can expose sensitive data to another user.
Least privilege and logging
A service should reach only the APIs and data it needs. API scope and database permission together reduce the impact of a compromised component. Tokens, passwords and sensitive content must not go into the log. A trace identifier is observability data, not proof of authorization.
Common misconceptions
Statement
Clarification
"On the internal network there is no need to authenticate."
The internal network is not automatically trustworthy.
"mTLS also gives authorization."
It gives identity; authorization must be decided separately.
"Decoding the JWT is enough."
The signature, issuer, audience and time must be checked too.
"A logged-in user may use any identifier."
Authorization must be checked record by record.
In short
TLS encrypts and identifies the server; mTLS identifies the client too.
Identity is not authorization.
Checking a JWT: algorithm, issuer, audience, subject, time conditions, key source.
Record-level authorization is enforced by the data owner service.
Review questions
What does mTLS prove, and what does it not decide?
Why must the service check the owner of the record even behind a gateway?
What mistake can a shared cache without tenant context cause?
Service Identity, mTLS and Authorization
Objectives
By the end of the lesson, you can explain what mTLS proves and what it does not, distinguish a service's identity from a user's authorization, and list the most important steps of checking a token.
Why is it needed?
Between services too, it must be checked who is calling, what they are authorised to do, and which resource they affect. The internal network is not automatically trustworthy: through misconfiguration, a compromised component or an accidentally public route, an unauthorised caller can also reach the service.
Encrypted connection and identity: TLS and mTLS
TLS (Transport Layer Security) provides an encrypted connection, and based on the server's certificate the client can check whom it is connecting to. According to RFC 8446 (TLS 1.3), a server that authenticates with a certificate may optionally request a certificate from the client as well. This is mTLS (mutual TLS): both parties prove their identity with a certificate. It can provide service or workload identity, but by itself it does not say what business operation the identified caller may perform.
Certificate management involves issuance, validity, renewal and the trust root. An expired or unknown certificate must not be "fixed" by switching off the check.
Service and user context
A call can be a pure service operation, or one performed on behalf of a user. The two must be distinguished: besides the service's own identity, the user's authorization and the tenant context may also be needed. A token issued for a public client should not automatically be forwarded to every internal service if they are not among the permitted audiences.
Checking a token (JWT)
If the context travels as a JWT (JSON Web Token), according to RFC 8725 (JWT Best Current Practices), among other things:
iss), and the value ofsubmust be compared with the application's known subjects;aud(audience) must be checked;kidand the URL fields specifying the key source (jku,x5u) can open the way to injection and SSRF, so they must be filtered;typheader).Decoding the content of a token is not authentication.
Object-level authorization
The entry point (gateway) can authenticate and apply a preliminary access rule. The service, however, is the data owner: it can decide whether the caller may modify the given record. The essence of BOLA (Broken Object Level Authorization), at the top of the OWASP API Security Top 10, is that the attacker changes an object identifier in the request and reaches data they would have no right to. According to OWASP, it is not enough to compare the session's user with the identifier; in every function that accesses data from client input, it must be checked whether the logged-in user may perform the operation on the requested record.
flowchart LR C["Client"] --> G["Gateway: authentication"] G --> S["Service: caller and scope"] S --> A["Record- and tenant-level authorization"] A --> D[("Own data")]The tenant identifier sent by the client must be compared with the trusted context. Caches, background work and event consumption must not lose this boundary: a cache or read model with faulty authorization can expose sensitive data to another user.
Least privilege and logging
A service should reach only the APIs and data it needs. API scope and database permission together reduce the impact of a compromised component. Tokens, passwords and sensitive content must not go into the log. A trace identifier is observability data, not proof of authorization.
Common misconceptions
In short
Review questions
Learning resources