ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
What is OAuth?
Why and when should you consider using it?
How do you use it?
Take a deep dive into the back-and-forth
Servers need to know who you are who you say you are
This process is called "authentication"
Related to (but different from) "authorization", which is deciding whether you get to do something
OpenID is an authentication framework, OAuth does a little of both
Client walks up to server: "I am Ted"
Server says "Prove it"
Client says "Here is a secret that only you and I know"
Server checks the secret
If it's the same, Server says, "Welcome!"
If it doesn't match, Server says, "Get lost"
Simpler is not always better
There are a few flaws here...
the server has to know the secret
the secret now is being passed over the wire
... so we introduce a slight wrinkle: hashes
cryptographic hash: a one-way function with tiny chance of false positive--- this takes "password" and turns it into something ("019385^234HghdjI[") that you can't reverse-engineer back to "password"
Client walks up to server: "I am Ted"
Server says "Prove it"
Client says "Here is the secret that only you and I know"
Client software hashes the secret
Server checks against the hashed secret stored on his side
If it's the same, Server says, "Welcome!"
If it doesn't match, Server says, "Get lost"
this still means a new password per website
this leads to vulnerability to the "mousepad attack"
this doesn't allow for any sort of third-party engagement
suppose another party wants to use my photos on your server?
think of this as the same kind of model when you give your car keys to the valet: you're letting them drive your car, but not go to your house and take a shower
Welcome to the problem that OAuth tries to solve
two flavors, OAuth 1.0 and 2.0
there's some controversy here... we'll get to that
For most platforms, this is generally a module plugin
Obtain an API key from the OAuth provider
Show the HTML widget
Create a landing page for the OAuth callback
Go forth and be happy
The players:** the User: the principal (typically a human) who has private resources stored with an OAuth-enabled site/server** the Client: the app/site that wants to access User's private resources** the Server: the OAuth-enabled site/server
For our example:** the User: Jane, who has just returned from Scotland with pictures and Scotch** the Server: Faji.com, a site for storing photos** the Client: Beppa.com, a site for printing and/or photos in an eco-friendly manner
From the user's perspective:** Jane visits Beppa.com, to print photos stored on Faji.com** Beppa.com has a widget that says "Sign in with Faji"; Jane clicks it** Beppa.com does magic to prove to Faji.com that it's legitimate** Faji.com agrees, and Beppa sends Jane to Faji to authenticate** Faji asks Jane if she's OK with Beppa accessing her photos** If Jane says yes, she's redirected back to Beppa** Beppa now has authentication tokens to access Jane's photos** Jane can always revoke Beppa's access at any time
From the Beppa.com developer (Dave)'s perspective:** Dave registers Beppa.com with Faji--- he receives a 'consumer key' and a 'consumer secret'
From Dave's perspective (continued):** Dave puts the "sign in with Faji" widget on his website*** when Jane clicks this widget, Dave takes the consumer key and secret and sends to Faji.com for a 'request token'*** on success, Beppa needs to redirect Jane back to Faji.com using the request token*** Jane is asked to authorize Beppa's access to her data (Dave does nothing here)*** if Jane said yes, Faji.com will redirect Jane back to Beppa to a URL of Dave's choice, saying that the request token is authorized*** Dave uses the request token to obtain an 'access token'*** Dave uses this access token with Faji.com's API for all authorized-requiring API calls
From the code library's perspective:** several URL parameters emerge out of this dance:*** oauth_consumer_key*** oauth_signature_method*** oauth_timestamp*** oauth_nonce*** oauth_callback*** oauth_signature*** oauth_token*** oauth_token_secret*** oauth_verifier
OAuth 1.0 was a community effort, not an official specification-- though it later became one (RFC 5849)
OAuth 2.0 was an official IETF specification from the start...-- and things are a touch different...-- but conceptually similar, to a degree
Community support** evenly split between 1.0 and 2.0--- lead author of 2.0 quit over the 'enterprisification' of 2.0** libraries help cover the difference** choose whichever you need; use the library, forget the rest
OAuth 2.0 brought a few enhancements and nomenclature** Less browser-centric--- One of OAuth 1.0's criticisms was that it mandated use of a browser** All communication is done over TLS (HTTPS)--- this prevents eavesdropping and man-in-the-middle attacks--- this also means less signing requests by hand** Tokens can expire and be re-authorized--- these use "refresh tokens"
OAuth 2.0 also changed up the players a little** Explicitly, four roles engage in the dance:*** an 'authorization server' for managing the access tokens*** a 'resource server' storing the resources*** the 'client', the site/app wanting access*** the 'resource owner', usually the customer/human*** OAuth 1.0 assumed the auth and resource servers were the same
OAuth 2.0 spec describes the flow between players slightly differently** several different flows, in fact, depending on desired outcomes** abstract OAuth 2.0 flow is:*** (A) client requests authorization from the resource owner*** (B) client receives an authorization grant (one of four types)*** (C) client requests an access token from the auth server, passing in the auth grant*** (D) auth server authenticates the client, validates the auth grant, and issues an access token*** (E) client requests resource from resource server, passing in the access token*** (F) resource server valides the access token, and serves the request** ... but all of this depends on the details
Official OAuth website
http://oauth.net
OAuth 1.0 Specification (RFC 5849)
OAuth 2.0 Specification (RFC 6749)
Google "OAuth Playground"
https://developers.google.com/oauthplayground
It will not protect against SQL injection attacks, for example
Nor will it save you from denial-of-service attacks
You're saving them the pain of having to remember a new password
But this is somewhat expected, so...
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Principal -- Neward & Associates
http://www.newardassociates.com
Educative (http://educative.io) Author
Performance Management for Engineering Managers
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)