oauth with oauth.io : solving the oauth fragmentation for identity management on the web

From authentication to identity

management

Mehdi Medjaoui

Mehdi Medjaoui

@medjawiwebshell.io

oauth.io

Authentication

I want to upload my photos to access them from anywhere

Photo.service

Photo.service

Hi Photo.service!

Photo.service

Hi! Who is it?

Photo.service

I’m Bob

Photo.service

Prove it!

Photo.service

Here’s my secret: ...

Photo.service

Oh it’s you Bob!

Photo.service

Here’s my secret: ...

Here’s my password

Why passwords?

Identification

Authentication = Identification + Verification

To correctly verify someone,a secret must relate to:

- what they know- what they have- what they are- what they can do

But why passwords???

In theory

Security vs Convenience

Photo.service

Photo.service Music.service

Photo.service Music.service Email.service

Social.service Video.service

Got cloudy these days...

Multiplication of web services have made passwords

- hard to remember if unique


- hard to remember if unique- annoying to type all day if strong

password hell


- hard to remember if unique- annoying to type all day if strong- weak if not unique

Passwords (even strong)do not scale

with a growing number of services

Solution = Password manager ?

simple interface design

Single Sign-On

Single sign-on (SSO) is a property of access control of multiple related, but independent software systems.

Single Sign-On

The promise of SSO:

- UX with frictionless sign in and higher conversion

- Reduced IT costs

- Retrieving data with user’s consent but without annoying

forms

- Reduced password leak risks

- SAML

- OpenID

- Facebook connect

- OAuth

- Persona

I’m Bob from IDP

IDPIdentity provider

Photo.service

Is it really Bob? IDP

Identity provider

Photo.service


Prove to me you’re Bob!

Photo.service


Here’s my session / password

Photo.service


You’re good

Photo.service


He’s indeed Bob.

Photo.service


Hi Bob! Gimme fotoz!

Photo.service

Photo.service

myspace

Yahoo

Google

?

The user makes the choice

- Based on URLs for personal data

http://google.com/profiles/meusername.wordpress.comblogname.blogspot.comwww.myspace.com/username

http://google.com/profiles/me

http://google.com/profiles/me

http://www.myspace.com/username

http://www.myspace.com/username

Authorization

I want to print my photos from photo.service with printer.service

The wrong way:

Printer.serviceneeds Resource

Photo.servicehas Resource

Key to photo.service



Hi, I want to print my photos.



Photo.service credentials?



Sure:



Hi I’m Bob & I have the key



You’re indeed Bob.



Please send me these photos



Here you go



I printed the photos.

Rogue Printer.service

needs Resource


I’m gonna look at all of Bob’s photos!

Rogue Printer.service

needs Resource


without his consent...

Never give your password to

other services

Authorization is the solution

Facebookhas Resource

some.serviceneeds

resource

Key to photo.service



Hi, I’m Bob.





I have support for Photo.service, ...

Note: choice of supported resource providers has also to be made by printer.service



I have support for Photo.service, ...

Please use Photo.service





Hi, I’m Printer.service



Prove it!



Here’s my client_secret



You’re good.



I need access to Bob’s photos



Who are you?

I’m Bob. Here’s my key





Do you allow Pr.S. to access your photos?

Sure!



You now have access to Bob’

s photos





Send me the holiday photos!

Here you go!





I printed the photos.


Note: Printer.service does not hold Bob’s key to Photo.service


The PHOTO app chooses and control what OAuth provider to

integrate, so the user cannot choose the identity he wants

Based on API authorizations and endpoints between applications

Single Sign-On conclusion

- 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.

OpenID OAuth SAML

Dates from 2005 2006 2001

Current version OpenID 2.0 OAuth 2.0 SAML 2.0

Main purposeSingle sign-on for consumers

API authorization

between applications

Single sign-on for enterprise

users

Protocols used XRDS, HTTP JSON, HTTPSAM, XML, HTTP, SOAP

OAuth and the Highway to Hell

OAuth 2.0 and the Road to Hell

(Eran Hammer)

OAuth 1.0 (2007)

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 user- agent redirections.

http://tools.ietf.org/html/rfc5849



OAuth 1.0 (2007)

Context : - php 4 - no https- Google involved- not Open ID

Pain:- Signatures- Broken libraries- Extensions - Crappy specifications

From Eran Hammer #FuckOauth

OAuth 2.0 - Looking Back and Moving On

OAuth 1.0a (one legged)

#OAuthBible

OAuth 1.0a (two legged)

#OAuthBible

OAuth 1.0a (three legged)

#OAuthBible

OAuth 1.0a (Echo)

#OAuthBible

OAuth 1.0a (xAuth)

#OAuthBible

OAuth 2.0

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

Flows

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

separate.

- OAuth 2.0 (Two-legged)

Client credentialResource 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 from providers….

#OAuthBible

OAuth is fragmented.

OAuth is broken.

OAuth 2.0 is a compromise.

Eran Hammer has quit the OAuth 2.0 Board.

He is building Oz.

Solutions to Consume OAuth ?

- The IETF specs- The OAuth Bible- Open source libraries (omniauth for ruby, requests or foauth for python, passport for node.js…)- Janrain, Dailycred- OAuth.io

OAuth.io

oauthd

Open source version of OAuth.io

https://github.com/oauth-io/oauthd/blob/master/providers

The Glue of OAuth?

https://github.com/oauth-io/oauthd/blob/master/providers/

https://github.com/oauth-io/oauthd/blob/master/providers/

OAuth Report #SOCIAL LOGIN

The future?

Mozilla Persona (Browser ID)

Docker.io

Thank you!

Mehdi Medjaoui

@medjawiwebshell.io

oauth.io

oauth with oauth.io : solving the oauth fragmentation for identity management on the web

Technology