Every request that reaches Tiffin's servers carries a silent question: who sent this? A customer checking their order, a kitchen tablet accepting it, a rider marking it delivered, the payment provider saying "this charge went through". If you get the answer wrong, someone sees another person's address, or a stranger marks a ₹900 order as delivered.
Authentication is how a request proves who it comes from. The next lesson covers authorization, which decides what that caller is allowed to do. Keep the two apart in your head. Most security bugs come from mixing them up.
This lesson is about the proof itself: passwords, sessions and tokens, and the ways each one breaks.
Who is calling Tiffin?
Tiffin has more kinds of callers than you'd first think, and they don't all prove themselves the same way.
| Caller | How it proves who it is | What goes wrong if it's weak |
|---|---|---|
| Customer app | Phone OTP once, then a session or token | Someone orders on your saved card |
| Kitchen tablet | A device credential, set up once | A fake tablet accepts and cancels orders |
| Rider app | Login, then a token | Fake "delivered" events, payouts to the wrong person |
| Payment provider | A signed webhook (see Module 22) | A forged "payment succeeded" gives away free food |
| Other Tiffin services | Mutual TLS or a service token | One hacked service can call all the others |
The pattern is always the same. The caller proves itself once, in an expensive way. Then it gets something cheap to show on every later request. That cheap thing is either a session or a token.