The ubiquitous model for web applications is to use browser cookies to associate state with a given user interaction. Typically, a cookie is used to identify the browser session, and then additional data is associated with that session over time: user authentication state, user identity, display preferences, shopping cart status, etc. Such data may be encoded in the cookie itself, or the cookie may be just a random ID that indexes session storage back on the server, or a hybrid approach of these.
Cookies have three major downsides:
- They are passed on every request, and hence cross-site request forgery is possible.
- They are a single token that represents all the state and authority the user has.
- State associated with the cookie cannot be carried outside the browser.
Belay enables the creation of applications without cookies: BCAP URLs are used to represent sets of authority and state. Like cookies, BCAPs are typically large random numbers and are mapped back at the server to data. But BCAPs differ in three ways:
- They are not passed automatically by the browser on every request. Instead, they are presented by the web application's front end when it wants to perform a particular action.
- Even for the same user and session, each BCAP can map to a subset of the user's authority and/or data. This property helps keep the web application code safer, and the security logic cleaner.
- BCAPs map not only to partuclar authority and data, but also specific action to be performed. In this way, granted authority can't be mis-applied to unanticipated operations.
Because they also map to actions, BCAPs can generally replace the API URLs that a web application uses to have the front-end communicate with the back.
In a typical Belay application, the "session" is actually carried by chains of these BCAP URLs, each granted to a particular function and data, and when invoked, each returning data, and often more BCAP URLs.
For example: Imagine a photo sharing site, showing a user the first dozen photos in an album. At the bottom of the page is a link for more.
Cookies Way: When it sent the page data being displayed, the back-end has included the album-id. When the front end processes the click on "more", it constructs a URL like: https://photosite.com/api/getAlbumImages?album-id=<album-id>&start-at=12&count=12. The back-end then receives this, along with the cookie. Using the cookie it retrieves the user account, then checks that they are authenticated (logged-in), and that they have access to the requested album, validates the start-at and count values, and finally returns the photo info.
Belay Way: When it sent the page data being displayed, the back-end included a BCAP URL for the next page. When granting this BCAP, it was associated with the current user, the album in question, and the starting point and count of the next page of photos. When the front end process the click on "more", it simply uses the supplied URL for fetching the next page data. It doesn't need to look at or manipulated this URL, which, for the curious, looks like this: https://photosite.com/cap/da6a9ed7-34ee-444b-b22c-1f1e1cde93c9. At the back-end, that BCAP URL is mapped back into the photo-page handler, which is invoked and passed the additional associated data: the album-id, starting point, and count. The handler need do no further authentication, and simply fetch and return the data.
A web application can use Belay in a hybrid mode, using cookies for initial user authentication, but once the user gets a legitimate first page, that page then carries all authorization in BCAPs.
A note about cross-site request forgery: The industry practice for protecting against cross-site request forgery is to generate a random token for each form sent to the front-end. The token is associated on the back-end with the particular form, data, and account it was generated for. When the form is presented, it includes the token, and checked for match. The token can't be used with another form or API call, or with another account. Thus the all powerful cookie can't be used by itself (as it is sent automatically by the browser) with forms and APIs protected by such tokens (which aren't sent automatically). BCAP URLs are just a generalization of this very idea, and which can make it simpler to code and build.