INF 123 SW ARCH, DIST SYS & INTEROP LECTURE 16 Prof. Crista Lopes

Objectives  Understanding the difference between Authentication and Authorization  Understanding OpenID and OAuth

Auth vs Auth  Authentication: who is this user?  Authorization: can this user do that?

Identity on the Web  Millions of Web sites, each with their own users  Each user needs to remember N usernames+passwords  …why not interoperate identity?  …why not interoperate more data?

Decentralized Identity OpenID

OpenID in Action  “OpenID is a decentralized authentication protocol that makes it easy for people to sign up and access web accounts.” 

How it works

How it works, in 11 steps Relying party OpenID Provider End Point

Steps 1, 2 – Post Identifier

How it works – Discovery Relying party OpenID Provider End Point

Steps 3, 4 – Normalization & Discovery  Yadis Protocol Content-Type: application/xrds+xml when performing an HTTP GET on the identity URL

Step 3 – XRDS response <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)" xmlns:openid="

Steps 3, 4 – Normalization & Discovery  Plain HTTP  Returned document must contain a element:

How it works – Redirect 1 Relying party OpenID Provider End Point

Step 5 – First redirect  Relying party parses XDSR or and retrieves the OpenID provider end point.  Then redirects (302, 303 or 307) user agent to it with query params appended to the URL: HTTP/ See Other Location: openid.ns= openid.mode=checkid_setup& openid.claimed_id=e_mumble& openid.return_to=

How it works – Login Relying party OpenID Provider End Point

Steps 6, 7, 8, 9 – Login  Undefined in the Spec  Usually regular login form with POST  May include further verification with user  This is a vulnerable point in the process  more later

How it works – Final Redirect Relying party OpenID Provider End Point

Step 10 – Final Redirect  OpenID Provider End Point redirects user agent back to the “return_to” URL. HTTP/ See Other Location: openid.ns= openid.op_endpoint= openid.return_to= openid.identity=e_mumble& openid.response_nonce= T17:11:51ZUN6TY9& openid.sig=MACsignature

Step 10  Relying party must verify a few things before deciding that the user is authenticated  return_to matches  identifier matches  nonce is unique  signature is valid

How it works – Finally! Relying party OpenID Provider End Point

Step 11  Relying party returns the page that user was on 

Final Remarks  The whole point of OpenID is to authenticate users  your web app wants to verify that user yahoo.com really is john.smith at yahoo.com  OpenID knows nothing about authorization  after establishing identity, your application must deciding which resources this user is allowed to access authentication ≠ authorization

OpenID is Phishing Heaven  idtheft.fun.de  OpenID’s adoption by major sites is a mystery to me!

Authorization – but not for *your* resources OAuth

 The goal of OAuth is to acquire an access token from a 3 rd party (like Google, Facebook, etc.), which can then be used to exchange user-specific data between your application and that 3 rd party service (such as calendar information or friends list) Facebook/Google user data Your app access user data

OpenID+OAuth  Lets arbitrary apps (like yours) access your Twitter/Facebook/Google/etc account without having to have your password

OAuth 4 main steps  Your app asks for a “request” token from the 3 rd party  Your app asks the 3 rd party for the token to be authorized  3 rd party requests user approval  Your app exchanges the “request” token for an “access” token  Your app uses the “access” token to access the data