Open Id, O Auth And Webservices
Upcoming SlideShare
Loading in...5
×
 

Open Id, O Auth And Webservices

on

  • 6,306 views

This presentation was given at Web Directions South in 2008. It is a developers guide to building sites using OpenID, OAuth and webservices - no code, but enough to point you in the right direction

This presentation was given at Web Directions South in 2008. It is a developers guide to building sites using OpenID, OAuth and webservices - no code, but enough to point you in the right direction

Statistics

Views

Total Views
6,306
Views on SlideShare
6,126
Embed Views
180

Actions

Likes
10
Downloads
189
Comments
1

3 Embeds 180

http://www.webdirections.org 165
http://www.slideshare.net 14
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • <br /><iframe width="350" height="288" src="http://www.youtube.com/embed/Kp1CB_1E4pc" frameborder="0"></iframe>
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Open Id, O Auth And Webservices Open Id, O Auth And Webservices Presentation Transcript

  • OpenID, OAuth and Webservices A developers guide Web Directions 2008 - Myles Eftos
  • Our lives in digits So many web apps - so many usernames, so many passwords How do we access our data? How can we do that safely ? How can we do it easily ?
  • Meet Jim Uses Twitter, Gmail, Digg, Newsgator, LinkedIn + many more His housemate finds his username and password Hilarity ensues
  • OpenID to the rescue! There are consumers, and there are providers Everyone gets a URL Magic happens…
  • Step 1 User enters their OpenID URL
  • Step 2 Consumer discovers link tags for delegation <link rel=&quot;openid.server&quot; href=&quot;http://my.openid.server&quot;> <link rel=&quot;openid.delegate&quot; href=&quot;http://madpilot.openid.server&quot;>
  • Step 3 Consumer redirects to the Provider login screen openid.mode = checkid_setup openid.identity = http://myid.openid.com openid.return_to = http://www.consumer.com?rp_nouce=[RANDOM] openid.trustroot = http://www.consumer.com
  • Step 4 User enters credentials
  • Step 5 Provider redirects to Consumer with return_url parameters openid.mode = id_res openid.return_to = http://www.consumer.com?rp_nouce=[RANDOM] openid.identity = http://madpilot.openid.com openid.signed = mode,identity,return_to openid.assoc_handle = [some hash] openid.sig = [Base64 encoded HMAC signature]
  • Step 6 Consumer POSTs back to validate what was returned openid.mode = check_authentication openid.signed = mode,identity,return_to openid.assoc_handle = [same hash as before] openid.sig = [Same Base64 encoded HMAC signature as before] openid.return_to = http://www.consumer.com?rp_nouce=[RANDOM] Openid.identity = http://madpilot.openid.com
  • Step 7 If the returned values look ok the Provider returns is_valid:true is_valid:true
  • And again with passion Dumb mode has lots of redirects Not-dumb mode asynchronously (AJAX) gets an immediate answer If the user is logged in, the user can continue If not, decide what to do (authenticate would be a good idea)
  • Simple Registration SREG to it’s friends Send your favourite parameters Pull nickname, email, date of birth, gender, country, language, time zone Consumer can request required and optional parameters
  • I want my data! Data in the cloud is cool Backups, hardware upgrades – someone else’s problem Vendor lock-in is the suck Web services are the awse
  • REST vs SOAP The world needs more religious wars Both lie on HTTP Both use XML* Remote Procedure Pattern vs. Resource Pattern * REST doesn’t really care…
  • SOAP : Why no one uses it In theory it rocks. Has a description language (WDSL) It is verbose Perhaps, something more Ideological?
  • REST : The web for computers The web is based on resources Type in a URL: GET that resource Submit a form: POST to that resource Forgotten verbs: PUT and DELETE
  • One end point to rule them all OK, maybe two Delete the company with id=1 DELETE /companies/1.xml Update the company with id=1 PUT /companies/1.xml Return the company with id=1 GET /companies/1.xml Creates a new company POST /companies.xml Returns all companies GET /companies.xml
  • HTTP/1.1 101 HTTP does a lot of stuff
  • HTTP/1.1 101 HTTP does a lot of stuff Status codes Authorization Required 401 Server Unavailable 503 Server Error 500 Invalid Entity 422 Gone 410 Not allowed 405 Not Found 404 Forbidden 403 Bad Request 400 Moved Permanently 301 Created 201 OK! 200
  • HTTP/1.1 101 HTTP does a lot of stuff Status codes Headers and modifiers If-Range If-None-Match If-Match If-Unmodified-Since If-Modified-Since
  • Communism doesn’t work You don’t want any old person changing stuff 401 Authorization Required Still needs a password though – a pure OpenID implementation is out Anti-password pattern alert!
  • Check up on Jim Signs up to a new Web 2.0 CRM Offers to copy contacts from Gmail Requires your Gmail username and password… Sounds phishy
  • Bloody OAuth it is… OAuth is a machine authorisation protocol Like a Valet Key Give permission for a system to access your account … or take away permission Again, there are Providers and there are Consumers
  • Step 1 User wants to access their photos from another service
  • Step 2 Consumer sends a POST request to the request token URL at the Provider. It identifies itself using a shared secret key that was prepared earlier
  • Step 3 The Provider returns a unauthorised request token. The token is good for one use
  • Step 4 The consumer redirects the user to the Authorisation URL of the provider
  • Step 5 If the user hasn’t logged in to the Provider service, they do so now on the Provider You could use OpenID for this bit
  • Step 6 The Provider asks the user if they really wants to let the Consumer have the photos
  • Step 7 The Provider redirects the user back to the Consumer and lets the Provider know that is can request a authorized token
  • Step 8 The Consumer requests an authorised token using the now authorised request token
  • Step 9 The Provider exchanges the request token for an access token. This token is good for a pre-determined period of time (Maybe forever)
  • Step 10 The Consumer can now access the data using it’s access token
  • Step 11 The Provider sends the data if the access token checks out
  • Look ma – no passwords! User never enters their password on the Consumer The Consumer actually has it’s own password (the token) The token can be revoked, stopping access
  • The Dark Side: OpenID Phishing DNS Spoofing Not an AUTHORISATION system Consumer has to trust the Provider Doesn’t really work without a browser
  • The Dark Side: REST No standard ! (Lather, rinse, repeat) No description language – requires more legwork
  • The Dark Side: OAuth Doesn’t work so well without a browser More complex/higher overhead than username/password Doesn’t work with cURL
  • Yadis with egg and cheese Service discovery protocol OpenID is the only open, distributed authentication system (Surprised?) XML RDF based Allows Providers and Consumers to negotiate protocols
  • Yadis with egg and cheese <?xml version=“1.0” encoding=“UTF-8”?> <xrds:XRDS xmlns:xrds=“xri://$xrds” xmlns=“xri://$xrd*($v*2.0)”> <XRD> <Service> <Type>http://lid.netmesh.org/sso/2.0</Type> </Service> <Service> <Type>http://lid.netmesh.org/sso/1.0</Type> </Service> </XRD> </xrds:XRDS>
  • You know what would be cool ? OpenID on your desktop OpenID on your mobile Webservice brokering system File system integration
  • Your local libraries OpenID: http://wiki.openid.net/Libraries OAuth: http://oauth.net/code
  • In conclusion, Thank You Question time starts… Now