Challenge 2: Bearer Token or mTLS? — Possible Solution
====================================================================

(a) A mobile app calling a public-facing gRPC gateway — BEARER TOKEN
AUTH. A mobile app is used by a human end user, authenticating via
some form of login/credential flow (the bc1 course's territory) — the
app itself doesn't have (and shouldn't need to manage) its own
certificate identity the way an internal backend service would. A
bearer token, obtained once after login and attached to calls, fits
this human-authenticated, external-client scenario naturally.

(b) An internal payments service calling an internal ledger service,
both within the same company's private network — MUTUAL TLS. This is
exactly gRPC's original service-to-service use case (Chapter 1): both
endpoints are backend services the same organization controls, with no
human involved in the exchange at all. Each service can be issued its
own certificate identity, and mTLS lets the ledger service cryptographically
verify that a call genuinely originated from the real payments service
— not just from whoever happened to know a shared secret or token,
which is a meaningfully stronger guarantee for high-stakes internal
traffic like payments-to-ledger calls.

THE UNDERLYING TEST, per this chapter's concept-grid: is the caller a
human/external client authenticating via credentials (bearer token), or
another internal service with its own verifiable identity (mTLS)?