Building a Secure API Platform

A data-driven approach

Who am I?

Malcolm Sparks, Founder & CTO @ JUXT

@malcolmsparks (GitHub, X, LinkedIn, etc.)

Languages

Who am I?

Projects

• Founded 2013
  • "to simplify the way the world develops software"
• Full stack development, Information Systems
• Lots of experience building APIs and API platforms

Introducing 'Site'

• Really, just a web server, backed by a database
• Web resources are documents, keyed by URI
• Each document contains metadata for how to handle the resource
  • Content negotiation
  • Conditional requests
  • Cacheing
• Operations are resources
  • Document defines database operations (in code), operations are the 'unit' of access control

Introducing 'Site'

• Web resources can be bundled, e.g.
  • OpenAPI
  • OAuth2
  • Your API
• OAuth2
  • grants: authorization_code + pkce, implicit, resource owner credentials, client_credentials
  • app registry, access token issuance
• Access Control
  • RBAC, ABAC, PBAC, ReBAC...
• 100% Open Source, written in Clojure (JVM)

Broken Object Level Authorization

https://owasp.org/www-project-top-ten/

Site is not an API gateway

Meeting the BOLA Challenge

• ABAC is hard, because attributes are domain-dependent.
  • unlike authentication, rate-limiting
• Build/test security into your application, at development time
  • i.e. on the developer's dev laptop/workstation
• Don't leave security to ops!
  • Tons of third-party security 'products', by definition, are domain independent

Site's permissioning model

• Each API endpoint/method pair maps to an operation
  • same as OpenAPI
  • e.g. CreateCustomer, RefundAccount, TransferFunds, ExtractMedicalDetailsForInsurer
• Permissions are database objects
• Permissions correspond to a single operation.
• Operations define the query/matching logic for which permissions are relevant when performing an operation.

  • operation.getPermissions(db, subject, resource)

• Currently implemented in a Datalog-like language