61 lines
3.4 KiB
Markdown
61 lines
3.4 KiB
Markdown
# OAuth3 - A SPEC we can Auth*x* with
|
|
All endpoints defined. All data described. All setup process automated.
|
|
|
|
The goal of OAuth3 is to establish a well-defined specification for Authentication and Authorization that gives the identity owner (i.e. the human that uses the Internet) the choice of where to store their identity (i.e. not just Facebook) and also gives the developer the ability to write code once that can work with *any* service that adheres to the spec (i.e. not just a limited pre-programmed list of Facebook, Twitter, and Google).
|
|
|
|
The specification was created with the intent that an entry level developer can copy a few files over to a static file server and copy a few lines of code into a web, mobile, or desktop application and have secure authentication in that application.
|
|
|
|
The ultimate goal of OAuth3 is to re-federate the Internet so that content creators (here's lookin at you "Insta" and "snap" celebs) have the choice of where to store their data and which services to use - whether on "the cloud" (large centralized systems) or on "home cloud" systems.
|
|
|
|
## Why not OAuth2?
|
|
|
|
OAuth2 started to solve an important problem, but it just didn't get there.
|
|
|
|
### OAuth2 can't be implemented.
|
|
|
|
OAuth2 isn't a protocol, it's "a framework for a protocol"
|
|
|
|
That sounds like nonsense, but it's important nonsense. A good specification should result in two or more people being able to read the specification, implement it, and without having communicated to each other at all, both of their implementations should be compatible - anyone who writes an application for one should find that it works for the other with 0 changes to the application.
|
|
|
|
This is not the case with OAuth2.
|
|
|
|
* The endpoints are not defined (i.e. /authorization_dialog vs /auth_diag vs /login)
|
|
* The doesn't define data format (i.e. urlencoded vs XML vs JSON)
|
|
* It does define internal implementation details (i.e. how the service should handle state)
|
|
|
|
## Why not OIDC?
|
|
|
|
OpenID Connect is an incremental improvement upon OAuth2. It is a step in the right direction,
|
|
but it too stops far short of the goals we have set.
|
|
|
|
### OIDC is built for enterpise, not for end-users
|
|
|
|
OAuth3 was in development simultaneously with OIDC and is being released long after OIDC,
|
|
as such many of the conventions of OAuth3 have been changed to match those of OIDC where
|
|
appropriate. However, they are still separate specifications with different goals.
|
|
|
|
Some of the failings of OAuth2 we see left unsolved in OIDC are that it
|
|
|
|
* focuses primarily on service providers, not identity and content owners
|
|
* cannot be made backwards compatible with OAuth2
|
|
* requires manual intervention by a developer to register an application and accept agreements
|
|
* requires manual intervention by users to accept License and TOS agreements
|
|
|
|
## Why OAuth3?
|
|
|
|
A protocol to enable machines to help people protect their identity - not just in "the cloud",
|
|
but also in the home.
|
|
|
|
### OAuth3 gives humans choice, works in the IoT-enabled home
|
|
|
|
* a single implementation is sufficient for all services and domains
|
|
* can be used in apps and on devices in the home
|
|
* all endpoints well-defined
|
|
* automated registration
|
|
* automated License and ToS acceptence
|
|
* more capability on the client means greater security and less server load
|
|
* *can* store identity on client devices or in "the cloud"
|
|
* does not *require* an application server (though that sure makes Interneting convenient)
|
|
* human-friendly
|
|
* machine-friendly
|
|
* no developer required |