Open Authentication API (OpenAuth)
-
Upload
sampetruda -
Category
Documents
-
view
6.691 -
download
20
description
Transcript of Open Authentication API (OpenAuth)
Open Authentication API (OpenAuth) & OpenID
Gregory Cypes, Principal Software Engineer
Report Title / Confidential 2
Why Identity ?
Well .. to identify the user for ….• Personalization• Authorization / Access Control• Communication• Content Publishing• Maintaining Public Identity across Providers
Report Title / Confidential 3
But … it is also
A barrier to entry•Registration == drop off•ID fatigue among users
Expensive to maintain authentication infrastructure
Report Title / Confidential 4
Identity evolution in AOL
• AOL Accounts (w/ account relations)
• AIM Accounts
• ICQ Accounts
• Delegated accounts – mac.com, userplane.com, etc.
• Domain based accounts – email address, vanity domains, personal domains, etc.
• Federated accounts – Verizon, hansenet, etc.
Report Title / Confidential 5
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
Report Title / Confidential 6
User-Centric Identity
•Providing user choice
•Privacy protecting
•Easy to adopt & use
•Allowing collaboration
•Supporting Long Tail applications
•Internet scale
Report Title / Confidential 7
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
Report Title / Confidential 8
OpenID http://openid.aol.com/screenname
Report Title / Confidential 9
a better picture …..
Report Title / Confidential 10
Challenges: Adoption
•Platform/OS dependencies
•Programming language support
•Too many APIs/protocols
•Complex message formats
Report Title / Confidential 11
Challenges: User Experience
•Sites with existing user base
•Same ID/Password every where
•Inconsistent login experience
•‘Deputization’ of services
•Redirects
Report Title / Confidential 12
Challenges: Permission Management
•Different ways to manage user permissions (consent)
•Implicit vs explicit
•Client vs server
•Decentralized consent management
•Managing given consents
Report Title / Confidential 13
Challenges: Security Issues
• XSS
• Phishing
• Authentication tokens for sites vs users
• Managing sessions (client side vs server side)
• Validating and invalidating authentication tokens
Report Title / Confidential 14
Challenges: Privacy Issues
•Same identifier everywhere
•Public vs private personas
•Anonymous and randomized identities
Report Title / Confidential 15
Open Authentication (OpenAuth)
Our answer to the problems of– Complexity– Service invocation– Simple Provisioning– Identity for Web 2.0 applications
Report Title / Confidential 16
Open Authentication API
•Simple API to Authenticate AOL/AIM/ICQ Users
•Light-weight “provisioning” and easy integration/use
•Well known/understood Technologies
• HTTP/TLS/XML/JSON/…•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)
http://dev.aol.com/openauth
Report Title / Confidential 17
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
Report Title / Confidential 18
Getting Started - WebApp/Client
1. Get devId from dev.aol.com/keys
2. Authenticate user to get an Auth Token1. Using “login” redirect - a href link or a auto redirect2. Using “getToken” in browser using JavaScript3. Using “directLogin/clientLogin” if you are building a client
3. Validate Token using “getInfo”1. If you need user loginId
4. Invoke AOL Open Services by passing Auth Token
Report Title / Confidential 19
Getting Started - Open Web Service
1. Design your APIs as per the AOL Open Services Standards1. http://wiki.office.aol.com/wiki/Open_Services
2. Integrate with AOL Auth (SNS/OpenAuth using VL or WebAPI)1. Document Auth related parameters in your API (token)
3. Validate Token - pass “reqRights” if you need user consent1. If you need internal user info (GUID) use “getInternalInfo”2. Otherwise “getInfo” is good enough
4. If “getInfo” or “getInternalInfo” returns consent error with url - return it to your client
Report Title / Confidential 20
Sign In Page
http://api.screenname.aol.com/auth/login?devId=xysdefe&succUrl=http://developer.aim.com/webaim&f=qs
Report Title / Confidential 21
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
Report Title / Confidential 22
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
Report Title / Confidential 23
Permission Request Page
http://api.screenname.aol.com/auth/getConsent?devId=xysdefe& succUrl=http://developer.aim.com/webaim&f=qs&tok=dsfsdflskdfjldfjkl
Report Title / Confidential 24
User Permission Management Page
https://my.screenname.aol.com
Report Title / Confidential 25
Q & A
•http://dev.aol.com/openauth•[email protected]• http://wiki.office.aol.com/wiki/Authentication
•http://authsupport.iweb.aol.com•[email protected]