Access Control

Twotle requires authorization but does not require authentication. Unless we trust all users to be trustworthy, how can we achieve one without the other?

“The definitions of trust and trustworthy are often confused. The following example illustrates the difference: if an NSA employee is observed in a toilet stall at Baltimore Washington International airport selling key material to a Chinese diplomat, then (assuming his operation was not authorized) we can describe him as ‘trusted but not trustworthy’. Hereafter, we’ll use the NSA definition that a trusted system or component is one whose failure can break the security policy, while a trustworthy system or component is one that won’t fail.” Ross Anderson, Security Engineering

Capabilities

Even when web apps have no user accounts, we can still control access to resources by taking advantage of capability URLs. In a capability URL such as https://doodle.com/inturicogmbh, the capability inturicogmbh must not only serve as an identifier and therefore be unique, but also be virtually unguessable.

We could generate the capabilities ourselves by careful, proper use of a cryptographic pseudorandom number generator, or we can leave the heavy lifting to Java’s java.util.UUID.randomUUID().

Unfortunately, there is an undeniable risk of exposure with capability URLs. Simply moving the capability to the URL’s query string would not mitigate the risk. However, we can move it to the fragment identifier and have the frontend pick it up and provide it to the backend via a request header.

While we are at it, we can split the capability into a regular identifier (without security properties) and an access token, separating the two concerns; this has the added benefit of allowing for revoking and re-issuing access tokens as well as for issuing tokens with differing access right: https://twotle.com/events/{EVENT_ID}#{ACCESS_TOKEN}