Open Authentication API (OpenAuth)
Upcoming SlideShare
Loading in...5

Open Authentication API (OpenAuth)






Total Views
Views on SlideShare
Embed Views



1 Embed 3 3



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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • well the more a user feels like a home the more frequently he is going to come back. Personalization helps in user retention. Every site/app always has some needs some kind of mechanism to control access, content management, etc.. And just like in physical world, people needs an address (an identifier) in virtual world too so they can communicate with each other. Or to publishing content or to leave comments, etc.
  • More identities == more passwords - more combinations to remember
  • To address these issues an user-centric identity model has been proposed as part of identity 2.0. Kaliya talked about user-centric identity on Monday in her session. Let’s take a quick look at what the high level design goals are. … … So conceptually looks very good but as with any new design models we need std protocols defined.
  • Identifier is an URL – it’s discoverable, addressable, clickable Talk about delegation, attribute exchange, simple registration extensions, etc.
  • CardSpace - Vista or IE7 (.net framework 3.0) only - other selectors are being built for various platforms - higgins is a open source framework for building CardSelectors and STS in java. Some have libraries already available in different languages - php, ruby, java, etc.. Some still do not have complete support (WS-* stack on Java for building STS for example.) Complex protocols and complex interactions. Developers/companies have to take a big overhead for training their developers to understand these new protocols and implement them (from scratch in some cases).
  • A very common question that we aalways hear “How are we going to explain what an openid is to my users ? “ It’s taking you the developers and product designers/manager weeks to understand the new protocols, how long is it going to take for an average user ? We are seeing a lot of Web 2.0 apps and sites that provide personalized services to the users. But how can a user securely allow some web application to do something on behalf of him ? Do you want to give away your id/pwds to them (like in ? How can the users securely delegate (may be wrong word to use - so let’s call it deputize) an action to a web/client application ? With redirects comes the big problem of phishing - users are always getting redirected from one site to another make it hard to understand who is asking for my credentials and where am I entering my password ! Obviously there are some interesting solutions coming up - like the one David Recorden demo’ed in his session today - a browser plugin that handles OpenId logins and makes sure you are only entering your password at your trusted IDP.
  • So we talked about deputization of services ealier. It’s all about * What a Service can do for me ? * What data or other services a Service can access on behalf of me ? * How to ensure Security and Usability ?
  • With all those challenges comes the never ending monster - security ! How many of you are like me - I am very optimistic - when I fix a security hole in my product I always say that’s the last one. Is it true ? Not really. Hackers work faster than developers.
  • When using identity online - some users understand the privacy issues and some don’t So its really an IDP’s job or responsibility to protect their users privacy or atleast allow ways to let the concerned users take care of it. Users should have ways to create public/private personas. In some cases for better user exp some might want to just chose simple aliases to their existing Ids.
  • Taking the best of each
  • “ Consent” is a permission granted to a site or application to do something, such as “Read Buddylist” If no consent, Open Auth returns “consent URL” with encrypted right to obtain consent for

Open Authentication API (OpenAuth) Open Authentication API (OpenAuth) Presentation Transcript

  • Open Authentication API (OpenAuth) & OpenID Gregory Cypes, Principal Software Engineer
  • Why Identity ?
    • Well .. to identify the user for ….
      • Personalization
      • Authorization / Access Control
      • Communication
      • Content Publishing
      • Maintaining Public Identity across Providers
  • But … it is also
    • A barrier to entry
      • Registration == drop off
      • ID fatigue among users
    • Expensive to maintain authentication infrastructure
  • Identity evolution in AOL
    • AOL Accounts (w/ account relations)
    • AIM Accounts
    • ICQ Accounts
    • Delegated accounts
        •,, etc.
    • Domain based accounts
        • email address, vanity domains, personal domains, etc.
    • Federated accounts
        • Verizon, hansenet, etc.
  • Online Identity ….
    • Lives moving online
    • Virtual world identity != physical world identity
    • Fragmentation of identity across services
    • Limits value of services (network growth slowed)
    • Not necessary to bind identity and services together
  • User-Centric Identity
    • Providing user choice
    • Privacy protecting
    • Easy to adopt & use
    • Allowing collaboration
    • Supporting Long Tail applications
    • Internet scale
  • Why OpenID ?
    • Simply, OpenID proves you own a URI
    • It does so by not dictating authentication
        • Screenname/password, Client certificates, e.t.c.
    • Model very similar to our Open Services model
        • Consumer, OpenID Provider and User
        • but it doesn’t provide token to boot strap authentication
    • Allows lightweight account creations and attribute exchanges
    • Lot of open source plugins/toolkits/SDKs available
    • Popular among the Web 2.0 apps and Social Networks
  • OpenID
  • a better picture …..
  • Challenges: Adoption
    • Platform/OS dependencies
    • Programming language support
    • Too many APIs/protocols
    • Complex message formats
  • Challenges: User Experience
    • Sites with existing user base
    • Same ID/Password every where
    • Inconsistent login experience
    • ‘ Deputization’ of services
    • Redirects
  • Challenges: Permission Management
    • Different ways to manage user permissions (consent)
    • Implicit vs explicit
    • Client vs server
    • Decentralized consent management
    • Managing given consents
  • Challenges: Security Issues
    • XSS
    • Phishing
    • Authentication tokens for sites vs users
    • Managing sessions (client side vs server side)
    • Validating and invalidating authentication tokens
  • Challenges: Privacy Issues
    • Same identifier everywhere
    • Public vs private personas
    • Anonymous and randomized identities
  • Open Authentication (OpenAuth)
    • Our answer to the problems of
        • Complexity
        • Service invocation
        • Simple Provisioning
        • Identity for Web 2.0 applications
  • Open Authentication API
    • Simple API to Authenticate AOL/AIM/ICQ Users
    • Light-weight “provisioning” and easy integration/use
    • Well known/understood Technologies
    • Permission (Consent) Management
    • Secure Token exchange for ‘ deputization’ of services
      • Designed for AOL Open Services Consumption
    • Supports Redirect, AJAX, and Direct Models
    • Also …
      • OpenID Provider (OP)
      • OpenID Authentication Token Exchange Extension
      • OpenID Consumer/Relying Party - accepts 3rd party OpenIDs
    • STS for CardSpace (in the future)
  • Quick overview of the API “ Bound” to a site by encoding referrer within token Unlike mcAuth, token, can be reused Must be URL-encoded in getInfo, getInternalInfo requests All Requests can be signed (md5/sha1/sha256) for additional trust level. Consent is obtained from user by authentication service Rights and messaging are configured in auth service Rights are service or API-specific: readBL, updateAB, etc
    • directLogin - validates a screen name and password
      • Authorized users only
      • Supports additional challenges
      • Requires shared secret for devId
    • getInfo - retrieve info about a token
      • loginId, displayName, token expiration
      • Determine if user has granted permission for site to access service
    • clientLogin - validates a screen name and password
      • Supports additional challenges
      • Session secret used to guarantee the usage of token from the same client
      • No shared secret is required
      • Available by end of Oct’07
    • getToken - retrieve authentication token for presentation to another site
    • login - retrieve HTML for sn/pwd entry
      • Not an “API” per se
      • Can be loaded in iFrame by AJAX apps
      • Requires shared secret for devId
    • logout - terminate session and invalidate auth tokens
    • getConsent - retrieve HTML form for obtaining user consent
    • getInternalInfo - retrieve internal info about a token, such as GUID
      • Restricted to AOL IP addresses
    • All APIs require devId and response format args
    • Supported formats are XML, JSON and Query String
  • Getting Started - WebApp/Client
    • Get devId from
    • Authenticate user to get an Auth Token
        • Using “login” redirect - a href link or a auto redirect
        • Using “getToken” in browser using JavaScript
        • Using “directLogin/clientLogin” if you are building a client
    • Validate Token using “getInfo”
        • If you need user loginId
    • Invoke AOL Open Services by passing Auth Token
  • Getting Started - Open Web Service
    • Design your APIs as per the AOL Open Services Standards
    • Integrate with AOL Auth (SNS/OpenAuth using VL or WebAPI)
        • Document Auth related parameters in your API (token)
    • Validate Token - pass “reqRights” if you need user consent
        • If you need internal user info (GUID) use “getInternalInfo”
        • Otherwise “getInfo” is good enough
    • If “getInfo” or “getInternalInfo” returns consent error with url - return it to your client
  • Sign In Page
  • Consent Management
    • “ Consent” is a permission granted to a site or application to do something, such as “Read Buddylist”, on behalf of a user
    • Verified upon request by OpenAuth service:
      • /auth/getInfo?a=<token>&devId=<devId>&reqRights=readBuddyList
      • Asks “tell me the identity represented by <token> and whether the user has given permission for <devId> to read his/her Buddy List”
    • If no consent, OpenAuth returns “consent URL” with the right to obtain consent for (encrypted)
    • Site/Application must redirect to or load consent URL in a browser
  • More on Consent
    • Consent will be enforced only if a Site/Service specifies one (reqRights)
    • Consent text is configured in OpenAuth servers
    • Grant Always and Grant Once buttons can be enabled/disabled on a per-right level
    • Stored in AKES (GrantAlways) or in Session Manager (Grant Once), by GUID
    • Trusted Sites/Application (based on devId) can be configured for “auto” implied consent
  • Permission Request Page succUrl=
  • User Permission Management Page
  • Q & A
      • [email_address]
      • http://
      • http://
      • [email_address]