This document summarizes the key challenges with OAuth implementations across different providers. It notes that while OAuth 1.0 and 2.0 were created to standardize authorization, in practice most major providers have implemented OAuth in non-standard and non-interoperable ways, with variations in parameters, response fields, API authorization methods, and scope formats. This has led to confusion for developers trying to support multiple providers. The document advocates for solutions that abstract away these differences to make OAuth usage simpler and more consistent.
13. 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
14. 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
18. 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
19. client_id -> app_id=...
scope -> perms=email,read_friendlists...
state=... [non documented]
response_type=code [useless]
โFacebook is the standardโ
OAuth.io@medjawii
DEEZER
20. 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
21. - 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
22. 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
23. 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)
24. 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 have
access_token: xxx
user_id: yyy
/user/yyy?access_token=xxx
26. 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
30. โ 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
31. - โ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!
34. - โ0 tokenโ paradigm
- No more secret key, everything public
The huge majority did not understand...
OAuth.io@medjawii
APRIL FOOL: INTRODUCING OAUTH 3.0
35. - โ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
36. Even if you are right,
3rd party developers will be lostโฆ because of
others providers already did it wrong before you
OAuth.io@medjawii
37. - โ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
38. โ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
44. 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
52. 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?
54. Open source : oauthd for on premises implementation to
consume your own oauth
https://github.com/oauth-io/oauthd
Easy contributions process,
with a small JSON to fill on github
OAuth.io@medjawii