9 Capability-based security and macaroons

 

This chapter covers

  • Sharing individual resources via capability URLs
  • Avoiding confused deputy attacks against identity-based access control
  • Integrating capabilities with a RESTful API design
  • Hardening capabilities with macaroons and contextual caveats

In chapter 8, you implemented identity-based access controls that represent the mainstream approach to access control in modern API design. Sometimes identity-based access controls can come into conflict with other principles of secure API design. For example, if a Natter user wishes to share a message that they wrote with a wider audience, they would like to just copy a link to it. But this won’t work unless the users they are sharing the link with are also members of the Natter social space it was posted to, because they won’t be granted access. The only way to grant those users access to that message is to either make them members of the space, which violates the principle of least authority (because they now have access to all the messages in that space), or else to copy and paste the whole message into a different system.

9.1 Capability-based security

9.2 Capabilities and REST

9.2.1 Capabilities as URIs

9.2.2 Using capability URIs in the Natter API

9.2.3 HATEOAS

9.2.4 Capability URIs for browser-based clients

9.2.5 Combining capabilities with identity

9.2.6 Hardening capability URIs

9.3 Macaroons: Tokens with caveats

9.3.1 Contextual caveats

9.3.2 A macaroon token store

9.3.3 First-party caveats

9.3.4 Third-party caveats

Answers to pop quiz questions

Summary

sitemap