A key technical underpinning of the Cloud are Application Programming Interfaces (API) - consistent methods for applications to interface with services in the cloud. More and more it will be through APIs that cloud data moves. The security of consumer APIs was threatened by the so-called 'password anti-pattern' – a model in which a client would collect and replay the password for a user at an API in order to access information on behalf of that user. OAuth not only defeats the password anti-pattern, but does much more. OAuth 2.0 defines a consistent, flexible identity and policy architecture for web applications, web services, devices, and desktop clients attempting to communicate with Cloud APIs. We'll discuss what OAuth provides, where it came from, and where its going.
About Paul Madsen
Paul Madsen is a Senior Technical Architect within the Office of the CTO at Ping Identity. He has served in various design, chairing, editing, and education roles for a number of federation standards, including OASIS Security Assertion Markup Language (SAML), OASIS Service Provisioning Markup Language (SPML), and Liberty Identity Web Services Framework (ID-WSF). He participates in a number of the Kantara Initiative's activities, as well as various other cloud identity initiatives. He holds an M.Sc. in Applied Mathematics and a Ph.D. in Theoretical Physics from Carleton University and the University of Western
About Brian Campbell
As Principal Architect for Ping Identity, Brian Campbell aspires to one day know what a Principal Architect actually does for a living. In the meantime, he tries to make himself useful by ideating, designing and building software systems such as Ping’s flagship product PingFederate. When not making himself useful, he contributes to various identity and security standards including a two-year stint as co-chair of the OASIS Security Services Technical Committee and a current focus on OAuth 2.0 within the IETF. He holds a B.A., magna cum laude, in Computer Science from Amherst College in Massachusetts. Despite spending four years in the state, he has to look up how to spell "Massachusetts" every time he writes it.
14. Ya&>A-#C&":;<&
• N0$%0*&3-H)&$-4(/C<&8((8&'&$/)*C&$-4(/C<&":;&(,,)<<&
$-&C($(_<)/H0,)<&$-&<#??A)3)*$_/)?A(,)&@/-4<)/&
(,,)<<&
• Salesforce.com expects that within the next year –
only 1/3 of access will be via browser&
• ":;<&-2&:((8&-e)/0*D<&(AA-4&$%)&,#<$-3)/&$-&)P?-<)&0$<&
-4*&,A-#C&<)/H0,)<&
• >A)(/&$/)*C&2-/&$%)<)&":;<&0<&$-4(/C<&6789&
31. A [confusing] Little History&
• First was the Emergence of Proprietary Solutions
– Google AuthSub, AOL OpenAuth, Yahoo BBAuth,
Upcoming API, Flickr API, AWS API, and more
• OAuth Core 1.0 [Oct 2007]
– Open protocol to standardize what was already being
done
• OAuth Core 1.0 Revision A [June 2009]
– Addresses a session fixation attack
• The OAuth 1.0 Protocol / RFC 5849 [April 2010]
– Move to the IETF as informational documentation of
1.0a with editorial clarifications and errata
33. B-/)&b0<$-/EK&8+AA&>-*2#<0*D&
• !"#$%&N6":&`N)@&6)<-#/,)&"#$%-/01(+-*&
:/-hA)<a [v(*&UZkZ]
– Better Support for non-web applications
– Simplify the Client
– Short lived, opaque, bearer access tokens with
long lived refresh tokens
– Cleaner separation of roles
• Server handling authorization requests
• Server handling protected resource access
• Client
– Simple Web Token (SWT)
• Attempt to standardize an access token format
• Oauth 2.0 [in progress]
75. cB"&.&!"#$%&
• User Managed Access extends OAuth 2.0 to allow for a user to manage
access to multiple (and distributed) resources through centralized
Authorization Manager
• Leverages separation between AS & RS introduced by WRAP
&
O4%,1' 9G4'
9%)&/)<-#/,)&<)/H)/&/)<?),$<&(,,)<<&$-5)*<& 9%)&%-<$&-#$<-#/,)<&(#$%-/01(+-*&w-@<&$-&
2/-3&Ñ0$<{&(#$%-/01(+-*&<)/H)/& (*&(#$%-/01(+-*&3(*(D)/&,%-<)*&@E&$%)&
#<)/&
9%)&(#$%-/01(+-*&<)/H)/&0<<#)<&$-5)*<& 9%)&(#$%-/01(+-*&3(*(D)/&0<<#)<&$-5)*<&
@(<)C&-*&$%)&,A0)*$f<&(@0A0$E&$-&(#$%)*+,($)I& @(<)C&-*&#<)/&?-A0,E&(*C&Ñ,A(03<{&,-*H)E)C&
@E&$%)&/)L#)<$)/I&
9%)&/)<-#/,)&<)/H)/&H(A0C($)<&$-5)*<&0*&(*& 9%)&%-<$&,(*&(<5&$%)&(#$%-/01(+-*&3(*(D)/&
#*<?),0h)C&3(**)/K&(<<#3)C&A-,(AAE& $-&H(A0C($)&$-5)*<&0*&/)(A&+3)I&
8$(+,&,A0)*$&/)D0<$/(+-*&<$)?&& B-/)&CE*(30,&3-C)A&
91. VA-4&
kI >A0)*$&(??A0,(+-*&/)$/0)H)<&8"BF&
(<<)/+-*&2/-3&A-,(A&;C:&
UI >A0)*$&<)*C<&8"BF&(<<)/+-*&$-&
:0*DV)C)/($)&($&8((8&:/-H0C)/_
?(/$*)/&)$,&
YI :0*DV)C)/($)&/)$#/*<&(,,)<<&
$-5)*&$-&,A0)*$&
RI >A0)*$&(??A0,(+-*&(CC<&(,,)<<&
$-5)*&$-&0$<&6789&/)L#)<$&-2&
6)<-#/,)&8)/H)/&`":;a&
XI 8((8&68&0*$)/(,$<&40$%&
:0*DV)C)/($)&$-&H)/02E&$-5)*K&
(*C&/)$/0)H)&C)<0/)C&(]/0@#$)<&
ÇI "<<#30*D&!oK&8((8&68&/)$#/*<&
/)L#)<$)C&C($(&$-&,A0)*$&
(??A0,(+-*&