Brief Introduction to OAuth

Wang Jiajun

Apr 22nd, 2014

Password

Almost everyone is familiar with password.

We use password for:

  • Various websites & applications
  • Debit card
  • Cryptography
  • ……

How Secure is Password?

Assume:

An n-bit password ([a-zA-Z0-9])

62n possible combinations

However…

Some Solutions

  • Different passwords for different sites :(
  • Transform the passwords
    • ppnn13%dkstFeb.1st
    • 娉娉袅袅十三余,豆蔻梢头二月初
  • Lastpass

Password is NOT Enough

Also some papers focus on password, e.g.

The Quest to Replace Passwords

Some other mechanism:

Android lock pattern

Too Many Passwords!

 

Too Many Passwords!

Multiple accounts/passwords in one site.

For example, in SJTU

{electsys,mail,jdcw,mypower}.sjtu.edu.cn

Single Sign-on (SSO)

  • Kerberos
    • MIT, in late 1980s
  • SAML
    • SUN, IBM, RSA, AOL,…
  • OpenID


We have Jaccount!

Why not Interoperate Identity?

OpenID

OpenID

An open standard

A decentralized SSO system

Allows users to be authenticated by certain site by a third party service.


Roles

  • Enduser
  • Identifier: A Url
  • Relying Party (RP): Third party website
  • OpenID Provider (OP)

An Example

Site: "Who are you?"

Me: "I am chris.vertonghen.org"

Site: "Prove it!"

(some magic happens)

Site: "OK. You are in."

Flowchart

Pros

Avoid redundant registering

No Leaking of your password

Better User Experience

Decentralized: Not owned by any one company

Cons

Website must support it

Phishing attack

Single point failure


OpenID is not Enough

OpenID gives us a way to quickly login

But we also need to fill in our profiles

Avatars, Nicknames, Email addresses, etc.

Suppose

You have multiple photos on Google+

Need to edit the photos, but on another site

Solutions

Download the photos and upload to the site

Give your Google account & password to this site

You have to fully TRUST the third party applications!

Why not Interoperate More Data?

Can we let the site only access to my photos while not knowing my password?

OAuth

OAuth

An authorization protocol
Allow users to grant a third party application to their protected resources.

Roles

  • Resource Owner: End user
  • Resource Server: Where protected resources exist
  • Client: Third party applications
  • Authorization Server: The server give you access token

An Example

Application: "I wanna know your name and get the access to your photos on Google+."

Me: "Alright."

(Application opens a website)

Google: "Do you really want to give it the access?"

Me: "Yes!"

(Google gives an access token to the application)

Google: "You can use the access token to do what you want (with the photos and the name)."

Application: "Cooooool!"

Flowchart

Real word examples

  • Pseudo-authentication
  • Third party client
  • Other applications

Case Study: Gmail

Configuring a email client, you need to provide:

username

password

{imap,pop3} server

smtp server

Google allow developers to use oauth api to control your accounts

Features

Scope

Revoke

Refresh

A Typical Website

Has its own accounts system

Integrated with OpenID(Always OAuth)

Binding its own user with a user's openid

Still very new

Looking good, but always some programming mistakes :(

从“黑掉Github”学Web安全开发

REST

Representational state transfer

Introduced and defined by Roy Fielding in 2000

Doctoral dissertation: Architectural Styles and the Design of Network-based Software Architectures

Web Service

A RESTful application

  • An Internet media type for data. JSON, XML……
  • Standard HTTP methods
    • GET
    • PUT
    • POST
    • DELETE
  • Server is stateless

A naive example

  • URI: http://example.com/resources/item17
  • Create: POST
  • Delete: DELETE
  • Replace: PUT
  • Retrieve: GET

An Example: WeChat

微信公众平台接口调试工具

Auth vs Auth

Authentication: who is this user?
Authorization: can this user do that?

Commonalities

Involves 3 parties

Open protocols

HTTP based (RESTful)

not mutual exclusive

Differences

Sharing: Identity vs Resources

Decentralized vs Centralized

EOF

OAuth

By Jiajun Wang

OAuth

A brief introduction to OAuth

  • 264