Title: Open Authentication API OpenAuth
1Open Authentication API (OpenAuth) OpenID
- Gregory Cypes, Principal Software Engineer
2Why Identity ?
- Well .. to identify the user for .
- Personalization
- Authorization / Access Control
- Communication
- Content Publishing
- Maintaining Public Identity across Providers
3But it is also
- A barrier to entry
- Registration drop off
- ID fatigue among users
- Expensive to maintain authentication
infrastructure
4Identity 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.
5Online 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
6User-Centric Identity
- Providing user choice
- Privacy protecting
- Easy to adopt use
- Allowing collaboration
- Supporting Long Tail applications
- Internet scale
7Why 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 doesnt 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
8OpenID
http//openid.aol.com/screenname
9a better picture ..
10Challenges Adoption
- Platform/OS dependencies
- Programming language support
- Too many APIs/protocols
- Complex message formats
11Challenges User Experience
- Sites with existing user base
- Same ID/Password every where
- Inconsistent login experience
- Deputization of services
- Redirects
12Challenges Permission Management
- Different ways to manage user permissions
(consent) - Implicit vs explicit
- Client vs server
- Decentralized consent management
- Managing given consents
13Challenges Security Issues
- XSS
- Phishing
- Authentication tokens for sites vs users
- Managing sessions (client side vs server side)
- Validating and invalidating authentication tokens
14Challenges Privacy Issues
- Same identifier everywhere
- Public vs private personas
- Anonymous and randomized identities
15Open Authentication (OpenAuth)
- Our answer to the problems of
- Complexity
- Service invocation
- Simple Provisioning
- Identity for Web 2.0 applications
16Open 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
17Quick overview of the API
- 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 Oct07
- 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
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
18Getting Started - WebApp/Client
- Get devId from dev.aol.com/keys
- 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
19Getting Started - Open Web Service
- Design your APIs as per the AOL Open Services
Standards - http//wiki.office.aol.com/wiki/Open_Services
- 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
20Sign In Page
http//api.screenname.aol.com/auth/login?devIdxys
defesuccUrlhttp//developer.aim.com/webaimfqs
21Consent 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?adevIdreqRightsre
adBuddyList - Asks tell me the identity represented by
and whether the user has given permission for
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
22More 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
23Permission Request Page
http//api.screenname.aol.com/auth/getConsent?devI
dxysdefe
succUrlhttp//developer.aim.com/webaimfqstokd
sfsdflskdfjldfjkl
24User Permission Management Page
https//my.screenname.aol.com
25Q A
- http//dev.aol.com/openauth
- SNS-Support_at_listserv.aol.com
- http//wiki.office.aol.com/wiki/Authentication
- http//authsupport.iweb.aol.com
- Open-Auth-Interest_at_listserv.sup.aol.com