OAuth with OAuth.io : solving the OAuth Fragmentation for Identity Management on the Web
This talk is about the story of password and identity management on the web.
It make an overview about passwod handling, single sign-on solution, OAuth and the future of it for the web, thanks Mozilla Persona and Docker.io Linux Containers.
It also present OAuth.io , a solution to solve framgementation.
- OpenID (URLs) is a group of companies that trust
each other to be an identity provider (IDP)
OpenID let the choice to the user of the IDP
- Facebook connect (Facebook Connect was the single
sign on of Facebook affiliate ecosystem)
- OAuth : the OAuth provider know the user AND the
application. The End user application choose the IDP
the end user can connect with.
Single sign-on authorization
Main purpose for consumers
OAuth and the
Highway to Hell
OAuth 2.0 and the
Road to Hell
OAuth provides a method for clients to access server
resources on behalf of a resource owner (such as a
different client or an end- user). It also provides a
process for end-users to authorize third-party access to
their server resources without sharing their credentials
(typically, a username and password pair), using useragent redirections.
- php 4
- no https
- Google involved
- not Open ID
- Broken libraries
- Crappy specifications
From Eran Hammer #FuckOauth
OAuth 2.0 - Looking Back and Moving On
Authentication and Signatures
- Stop cryptographic requirements of
signing requests with the client ID and
secret and replaces signatures with
requiring HTTPS for all
communications between browsers,
clients and the API.
User Experience and Alternative Authorization
OAuth 2 supports a better user experience for
native applications, and supports extending
the protocol to provide compatibility with
future device requirements.
Performance at Scale
- Many steps require state management and temporary
credentials, which require shared storage and are
difficult to synchronize across data centers.
- requires that the API server has access to the
application's ID and secret, which often breaks the
architecture of most large providers where the
authorization server and API servers are completely
- OAuth 2.0 (Two-legged)
Resource user password
- OAuth 2.0 (Three-legged)
- OAuth 2.0 (Refresh token)
Scopes are often not implemented the good way,
following the specs.
Sometimes spaces are not set, names are different