Your SlideShare is downloading. ×
Open ID and Django
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Open ID and Django


Published on

Slides from a lightning talk I gave at DjangoCon '10 regarding the usefulness of OpenID as a single sign-on solution for multiple Django sites.

Slides from a lightning talk I gave at DjangoCon '10 regarding the usefulness of OpenID as a single sign-on solution for multiple Django sites.

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. OpenID... and Django and Django
    • Nathan Florea
    • The Wenatchee World
  • 2. What is OpenID?
    • An open standard for decentralized authentication.
    • Internet-based single sign-on.
    • Unique identities based on URIs (or XRIs, if anyone cares).
    • A failure.
  • 3. Why?
    • Here’s two reasons:
      • Unwieldy, unfriendly usernames.
      • Isn’t very useful.
  • 4. Unwieldy usernames
        • I was excited about OpenID.
        • I set one up for my dad.
  • 5. Unwieldy usernames
    • Me: Hey, Dad, I'm going to set you up with an OpenID. It'll be . Now you'll be able to use that and a single password to log in to some sites instead of having to create five different accounts all named carlflorea using the same, single password. Isn't that cool?
  • 6. Unwieldy usernames
    • Dad: What would my username be again?
  • 7. Unwieldy usernames
    • Me: .
  • 8. Unwieldy usernames
    • Dad: Umm, did you see the Sounders game last night?
  • 9. Unwieldy usernames
    • Me: No, but I'm going to watch it lat-
  • 10. Unwieldy usernames
    • Dad: They won.
  • 11. Unwieldy usernames
    • Me: Thanks, Dad.
  • 12. Unwieldy usernames
    • A failure.
    • Turns out, my friends and family (“users”) don’t like URLs.
    • Here’s one of their URLs: “google Wenatchee falling cow.”
      • Except Weird Uncle Tom, who says “bing Wenatchee falling cow”.
        • (we don’t talk to Uncle Tom.)
  • 13. Not very useful
    • OpenID provides authentication.
    • OpenID doesn’t provide anything else.
    • My friends and family (“users”) use Facebook.
    • They expect more.
  • 14. Not very useful
    • Simon Willison launched a new social conference directory site, .
    • Simon Willison is a huge supporter of OpenID.
    • Lanyrd only authenticates through Twitter.
  • 15. Not very useful
    • He took some flack for that.
    • His explanation:
    • I spent the best part of three years advocating OpenID not just because of a belief in openness, but because of the things I wanted to build with it. I wanted to build sites that already knew about you before you even signed in. I wanted to be able to pull in information about you and your relationships from other providers. I wanted to use your public, globally unique ID to share (non creepy) information about you with other sites.
    • Then I got bored of waiting. By plugging in to the Twitter ecosystem I get all of those advantages, but I can actually build something successful and popular today.
  • 16. Not very useful
    • Developers and users are willing to give up some control of their online identity in exchange for cool stuff.
    • Twitter, Facebook, Google provide authentication PLUS a social graph.
  • 17. and Django and Django
    • Well, not a total failure.
    • Very cool technology.
    • Internet-based single sign-on.
    • Where is that useful?
  • 18. and Django and Django
    • You have multiple, cool Django sites.
    • You are building more all the time.
    • You want your users to be able to use a single account for all of your sites.
    • Solution:
      • Facebook!
  • 19. and Django and Django
      • No. You want:
        • Control.
        • Something simple.
        • With wide support.
        • You don’t need a social graph.
        • You only need your users to login.
      • Solution:
          • OpenID!
  • 20. Integrating OpenID with Django
      • To use OpenID with Django, you need to:
        • Setup an OpenID provider, the server to authenticate against.
        • Install an OpenID consumer app on all of your Django sites.
  • 21. OpenID Enabled
    • Lots of consumer apps, only a couple providers.
    • Everything based off Janrain’s OpenID libraries.
      • Every useful web language - and PHP.
      • For Python, openid.
  • 22. Setup the provider
    • We use openid_provider.
      • Somewhat active development.
      • Works.
  • 23. Setup the provider
      • Unique URL for your OpenIDs.
        • Example:
      • Pretty straightforward
      • Will want to create a signal on User creation to create an OpenID at the same time.
  • 24. Setup the consumer
    • Launchpad’s django_openid_auth for consumer.
      • Active development.
      • Authentication backend, integrates with Django User.
      • Allows URL “cheating.”
  • 25. Setup the consumer
      • Install app on each Django site.
      • Configure.
      • Allows “cheating” on the OpenID URLs.
        • OPENID_SSO_SERVER_URL = “ http://id.mydomain/openid/ ”
  • 26. That’s good. But I want a little bit more...
      • That solves authentication.
      • But each Django site still duplicates a lot of user information.
      • How can I centralize that, too?
  • 27. Introducing: SREG
    • Simple Registration (SREG).
    • Extension to OpenID.
    • Allows consumers to request additional information from providers.
    • Very basic info, such as preferred username and e-mail, but:
    • Extensible!
  • 28. Introducing: SREG
    • Can consolidate all user information on your provider.
    • Parcel out relevant information to consumers through SREG.
      • Example: Is user subscribed to consumer1’s newsletter? Only consumer1 cares.
    • Sync only occurs on login, probably still want to do some background syncing.
  • 29. Result
    • User with account visits for the first time and clicks the login link.
    • User redirected to to login.
      • Ajax allows this to all happen in the background.
      • Just uses username (e.g. “user1”), doesn’t have to worry about URIs.
      • New User created on consumer1 linked to OpenID.
    • User clicks login on, automatically logged in with no username or password entry.
  • 30. Catches
    • Biggest one is session cookies:
      • Consumer1, consumer2, and provider all have different session cookies.
      • User logs out of consumer1, you redirect to also log out of provider and then return, the user is still logged in on consumer2. May or may not be a problem.
  • 31. In conclusion
    • Urls:
  • 32. In conclusion
    • Will post a live example, a provider and two consumers, after the weekend, plus source.
    • Look for a tweet to #djangocon.
    • Contact me if you have are curious or have questions:
    • @florean
    • [email_address]