User Controlled Authorization Networks (UCANs) are a way of doing authorization where users are fully in control. OAuth is designed for a centralized world, UCAN is the distributed user controlled version.
Read the blog post for a high level description:
At a high level, User Controlled Authorization Networks (UCANs) are a way of doing authorization (“what you can do”) where users are fully in control. There’s no all-powerful authorization server, or server of any kind required. Everything that a users is allowed to do is captured directly in a key or token, and can be sent to anyone that knows how to interpret this format.
Since all Fission accounts are equipped with a global ID and cryptographic keys, we were able to design a system that has very few assumptions and thus works in a huge number of situations.
This setup has several advantages:
- Low effort: developers don’t need to write and maintain complex access logic
- Familiar: uses very common JSON Web Tokens (JWTs)
- Invisible: users don’t need to know that anything special is happening
- Flexible: access can be granted as coarse or granular as the end users wants
- Scalable: no auth server bottleneck / scales infinitely
- Secure: military-grade encryption
- Collaborative: users and services and delegate a subset of their access to others
- Self-contained: the token contains all the information needed to verify it
UCANs are all that we need to sign into multiple machines, delegate access for service providers to do things while we’re offline, securely collaborate on documents with a team, and more. We get the flexibility of fine- or coarse-grained control, all controlled by the one who cares about the data the most: the user.
We’ve implemented this as the authorization system for Fission, and are also making this available as a building block for developers to solve user authorization and delegation within their own applications.
Specification
The whitepaper contains the specification and is kept up to date: https://github.com/ucan-wg/spec
If there is interest, we can look at moving the specification into its own repo.
UCAN is specified on top of and alongside of a number of other standards.
Decentralized Identifiers
We use the did:key format.
JSON Web Tokens (JWT)
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
We chose JWT as the message format, since it is widely available in many programming languages and frameworks, and familiar to web developers.
Macaroons
The concepts of Google’s Macaroons – aka “stacked cookies” – informed a lot of the early design. We are more of a flipped model than how Google uses this, but they are looking to solve the same issue of centralized auth not scaling.
Simple Public Key Infrastructure (SPKI)
Pronounced spoo-key, SPKI (Wikipedia) also came up in research on Macaroons and we share a lot of core concepts with.
Implementations
Haskell
Server and client side in the fission repo:
TypeScript
webnative SDK:
Go
By the Qri team:
yes, we will make you a custom mascot if you implement UCANs in another language
Tools
UCAN Check
A UCAN validator and explorer.
Extensions
UCAN permissions for BLS co-signing
We developed a BLS co-signer module to put Filecoin and other private keys securely in the browser. The user’s webnative account stores part of a BLS private key, and with the UCAN, permission is granted by the user to the app to combine it with the co-signer key.
The implementation is described in the Phase 2 write up, and you can try it live at https://ancient-round-crab.fission.app
Presentations & Blog Posts
Coding Earth Meetup: Authorizing Users without a Backend, Brooklyn Zelenka
