I like bearer tokens, but the author's terminology makes it sound like they're not thinking about them from an appropriate perspective. My preferred way to thi

I like bearer tokens, but the author's terminology makes it sound like they're not thinking about them from an appropriate perspective. My preferred way to think about tokens is a form of inter-process communication. In a scenario like 'view this document requires authorisation', the token is a way for the the 'decide whether to authorise' process to communicate some data to the 'view the document' process (that data being 'document-viewing is authorised'). Statements like 'bearer tokens allow hackers to impersonate a user' isn't congruent with what tokens are, or what they're for; in particular, tokens have no concept of "user", "logged in", "authentication", etc. They simply communicate data from one system to another. The author's complains would be better phrased like "Caching authorisation results is vulnerable to time-of-check-to-time-of-use problems"; that's true regardless of the underlying technology. Finally, I also consider tokens to be a 'last resort'. From a capability perspective, unauthorised clients should be unable to say what they want; for example, we can restrict access to a document by making its access URL secret and unguessable (we should also allow fresh URLs to be generated, and old ones to be revoked/deleted). That's (a) safer than telling everyone where the document is then having to decide which requests to allow/forbid, and (b) easier to use and integrate into other systems (since it's just a URL; no cookies, "are you a robot?" captchas, etc.). If we're faced with an action that can't be made secret on its own (like gating it behind an unguessable URL), then we can make it secret by requiring an extra "dummy" parameter; AKA a 'token'. Note that this is the complete opposite of what the author seems to be describing, which is: - Reaching for tokens first (rather than as a last resort) - Having them represent "data" which isn't related to the actions being performed (e.g. "this is person X", rather than "document Y is readable") - Using this one token to access everything, rather than using fine-grained action-specific authorisation