We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A bank has 500 internal services that communicate with each other millions of times per day. Each service needs to authenticate to the others. Using passwords or API keys for machine-to-machine auth means managing and rotating 500 secrets across 500 services. A leaked key compromises the entire chain. Password-based auth also does not prove identity cryptographically. Anyone with the key can impersonate the service.
Certificate-based authentication gives each service (or user) a unique X.509 certificate signed by a trusted CA. The certificate contains a public key. The service proves its identity by demonstrating ownership of the corresponding private key through a cryptographic challenge-response, without transmitting a secret.
No passwords to leak. No API keys to rotate manually. Identity is proven mathematically. Google's internal network has operated on certificate-based service identity since the BeyondCorp project (published 2014), and every call between Google services is authenticated this way.
Certificate-based authentication replaces the "send a secret" model with a "prove you hold the key" model.
The flow works as follows. The client initiates a TLS connection and presents its X.509 certificate. The server checks three things: is the certificate signed by a CA I trust? Is it within its validity period? Has it been revoked? If all checks pass, the server sends a random challenge. The client signs the challenge with its private key. The server verifies the signature using the public key from the certificate. If the signature is valid, the client is authenticated.
The private key never crosses the network. This is the fundamental advantage over passwords. An attacker who intercepts the entire exchange cannot impersonate the client because they do not have the private key.