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


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 – mac.com, userplane.com, 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 http://openid.aol.com/screenname


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

• 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


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

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


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


Sign In Page

http://api.screenname.aol.com/auth/login?devId=xysdefe&succUrl=http://developer.aim.com/webaim&f=qs


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

http://api.screenname.aol.com/auth/getConsent?devId=xysdefe& succUrl=http://developer.aim.com/webaim&f=qs&tok=dsfsdflskdfjldfjkl


User Permission Management Page

https://my.screenname.aol.com


Q & A

•http://dev.aol.com/openauth•[email protected]• http://wiki.office.aol.com/wiki/Authentication

•http://authsupport.iweb.aol.com•[email protected]

Documents

Open Authentication API (OpenAuth)