OAuth in the Real World

APIdays Berlin

@medjawii

OAuth.io@medjawii

APIscene.com.

Are you getting the maximum from OAuth?

OAuth.io@medjawii

Identity provider

Identity consumer

(Application)User

OAuth.io@medjawii

OAuth.io@medjawii

OAuth provider

OAuth consumer(Application)

User

OAuth.io@medjawii

OAuth.io@medjawii

OAuth.io@medjawii

OAuth provider

OAuth consumer(Application)

User

The business value data is concentrated mainly on the provider and the consumer

OAuth.io@medjawii

OAuth provider

OAuth consumer(Application)

User

OAuth enables to concentrate the business

value data on the provider side.

OAuth.io@medjawii

The tale of 2 OAuth...

OAuth.io@medjawii

OAuth 1.0/1.a- Released in October 2007

- Revised in June 2009 (Revision A)

- Hard to implement with signatures, no expiration of tokens, no control the level

of access requested.

Some implementations have tried to get around these problems, which causes interoperability issues

OAuth.io@medjawii

OAuth 2.0- Non-backward compatible alternative.

- Several drafts from January 2010 and October 2012 where published as RFC 6749

- Facebook and many others implemented it when not final

- OAuth 2.0 is more flexible, wide range of non-interoperable implementations

- less secure than OAuth 1.0, relying on SSL connections rather than signatures to

protect the user’s access token,

- Easier to install when developing clients

OAuth.io@medjawii

The tale of 2 OAuth...

OAuth.io@medjawii

The tale of too many OAuth...

OAuth.io@medjawii

10 OAuth implementations you can’t guess…

that differ from RFC6949

OAuth.io@medjawii

Refresh_token grant_type: "refresh_token" => grant_type: "fb_exchange_token"refresh_token: "{{refresh_token}}" => fb_exchange_token: "{{refresh_token}}"

scope “notation”: friends_actions.music, friends_actions.video

Separator is a “,” instead of “%20“

OAuth.io@medjawii

FACEBOOK

client_id -> app_id=...

scope -> perms=email,read_friendlists...

state=... [non documented]

response_type=code [useless]

“Facebook is the standard”

OAuth.io@medjawii

DEEZER

More parameters options for the authorization form:

access_type: to choose to send a refresh_token or not

approval_prompt to force the popup even if we are already connected

login_hint to select an account or prefill the email address

include_granted_scopes to add more authorizations “incremental

authorization”

OAuth.io@medjawii

GOOGLE

- Some OAuth libraries expect to pass the OAuth token as access_token instead of oauth_token, since this is the expectation created by Facebook, at odds with earlier versions of the OAuth spec. We may add support for both parameter names, depending on feedback, but for now know that this may come up.

- No scope.

OAuth.io@medjawii

FOURSQUARE

Added custom authorization parameters:

immediate: whether the user should be prompted for login and

approval

display: template web, mobile, popup

login_hint: to prefill an email

prompt: prompt the user for reauthorization or reapproval

OAuth.io@medjawii

SALESFORCE

OAuth.io@medjawii

SALESFORCE

the authorization returns custom fields: - “instance_url”: the api url binded to a resource server, this is the only way to receive the domain - a signature: can be used to verify the identity URL was not modified (id & date signed with a private key) - issued_at instead of expires_in : salesforce prefers to give the issued time instead of the expiration duration - id_token: to support openid

UX for creating an app (4 not-so-easy to find mouseclicks between login & the app creation form)

Added authorizations parameters: API version

The authorization returns the user id, that is needed to call the api relative to the authorized user (there is no /me/..., /self/... or so)

OAuth.io@medjawii

VK

Instead of access_token: xxx/user/me?access_token=xxx

You haveaccess_token: xxxuser_id: yyy/user/yyy?access_token=xxx

scope “notation”: profile:write profile:read

OAuth.io@medjawii

23ANDME

OAuth.io@medjawii

Authorization parameters : chinese language only

oauth_version=2.a (useless parameter)

Extra : Chinese/English documentation for OAuth1.0 but Chinese documentation only for OAuth2.0

TENCENT WEIBO

And this is not exhaustive.

api.provider.com/path/action?access_token=TOKEN

api.provider.com/path/action?oauth_token=TOKEN

api.provider.com/path/action?token=TOKEN

Authorization HTTP header: Bearer TOKEN

Authorization HTTP Header: OAuth TOKEN

OAuth.io@medjawii

API CALLS AUTHORIZATION

OAuth.io@medjawii

SCOPE

scope=email%20publish

scope=email,publish

scope=email;publish

scope=email:publish

scope=email|publish

scope=read_only or scope=read_write

● inexistent (dailymotion, eventbrite...) so you have to put it in the callback

● undocumented (wordpress, deezer...)

● impossible (angelist.co) “fixed callback url”

OAuth.io@medjawii

THE “STATE” PARAM

- “OAuth is not so hard to understand”

- “It will be easier to it in this non-standard way”

- “Developers just have to read our documentation”

WHAT YOU SHOULD NOT TELL ABOUT OAUTH!

OAuth.io@medjawii

Introducing OAuth 3:0

- “0 token” paradigm

- No more secret key, everything public

The huge majority did not understand...

OAuth.io@medjawii

APRIL FOOL: INTRODUCING OAUTH 3.0

- “OAuth is not so hard to understand”

- “It will be easier to it in this non-standard way”

- “Developers just have to read our documentation”

WHAT YOU SHOULD NOT TELL YOURSELF ABOUT OAUTH

Even if you are right,

3rd party developers will be lost… because of

others providers already did it wrong before you

OAuth.io@medjawii

- “OAuth is not so hard to understand”

- “It will be easier to it in this non-standard way”

- “Developers just have to read our documentation”

WHAT YOU SHOULD NOT TELL YOURSELF ABOUT OAUTH

“In a design perspective,

documentation is a bug, not a feature”It is the most important but the last place to find information

OAuth.io@medjawii

OAuth.io

100+ providers unified and simplified

OAuth.io@medjawii

OAuth.io@medjawii

To retrieve your token

OAuth.io@medjawii

- Register on OAuth.io

- Click on the OAuth provider you want in the list

- Share your credentials

- Click on “try me“

That’s it, you have your token.90 seconds after signup.

PROCESS

OAuth.io@medjawii

What about generating

a pop-up?

OAuth.io@medjawii

OAuth.initialize("OAUTHIO_KEY");

OAuth.popup('facebook', function(err) {

if (err) {

// do something with error

}

OAuth.io@medjawii

OAuth.initialize("OAUTHIO_KEY");

OAuth.popup('twitter', function(err) {

if (err) {

// do something with error

}

OAuth.io@medjawii

OAuth.initialize("OAUTHIO_KEY");

OAuth.popup('salesforce', function(err) {

if (err) {

// do something with error

}

OAuth.io@medjawii

OAuth.initialize("OAUTHIO_KEY");

OAuth.popup('yourcompany', function(err) {

if (err) {

// do something with error

}

OAuth.io@medjawii

And for deeper APIs calls?

OAuth.io@medjawii

OAuth.popup('twitter', function(err, res) {

if (err) {

// do something with error

}

res.get('/1.1/account/verify_credentials.json')

.done(function(data) {

alert('Hello ' + data.name)

})

})

OAuth.io@medjawii

OAuth.popup('twitter', function(err, res) {

if (err) {

// do something with error

}

res.get('/1.1/account/verify_credentials.json')

.done(function(data) {

alert('Hello ' + data.name)

})

})

No need to call your own server and to sign your API request and send it

back

No more access token management, it’s now completely abstracted

It feels lighter right?

For web and mobile

OAuth.io@medjawii

Open source : oauthd for on premises implementation to consume your own oauth

https://github.com/oauth-io/oauthdEasy contributions process,

with a small JSON to fill on github

OAuth.io@medjawii

OAuth.io@medjawii

THANK YOU