Gluecon oauth-03

64
OAuth – authen+ca+on & authoriza+on framework for REST APIs Paul Madsen Ping Iden+ty

description

 

Transcript of Gluecon oauth-03

Page 1: Gluecon oauth-03

OAuth  –  authen+ca+on  &  authoriza+on  framework  for  REST  APIs  

Paul  Madsen  Ping  Iden+ty  

Page 2: Gluecon oauth-03
Page 3: Gluecon oauth-03
Page 4: Gluecon oauth-03

Authen+ca+on  for  SOAP  

•  The  SOAP  world  has  long  had  standards  related  to  authen+ca+on  &  authoriza+on  of  web  services  

•  WS-­‐Trust  defines  a  protocol  by  which  a  SOAP  client  can  obtain  a  security  token(typically  a  SAML  asser+on)  

•  WS-­‐Security  s+pulates  how  to  aKach  the  token  (SAML  asser+on)  to  a  SOAP  request  

Page 5: Gluecon oauth-03

But  …..  

Page 6: Gluecon oauth-03

1)  REST  authen+ca+on  •  REST  world  has  not  had  comparable  standards  

•  Nothing  comparable  to  WS-­‐Security  -­‐  mish  mash  of  HTTP  Basic,  HTTP  Digest,  password,  and  SSL  for  message  authen+ca+on    

•  Nothing  comparable  to  WS-­‐Trust  –  consequently  client  bears  burden  of  managing  creden+als  &  trust  

Page 7: Gluecon oauth-03

2)  Password  an+-­‐paKern    

Site  asks  YOU  for  your  GOOGLE  password  so  it  can  access  your  Google  stuff.  

Page 8: Gluecon oauth-03

Tsk  tsk!  

•  Teaches  users  to  be  indiscriminate  with  their  passwords  

•  Doesn’t  support  granular  permissions,  e.g.  X  can  read  but  not  write  

•  Doesn’t  support  (easy)  revoca+on  –  to  be  sure  of  turning  off  access  users  must  change  password  

Page 9: Gluecon oauth-03

Importance  of  revoca+on  

WTF  is  this  thing?  

I  should  use  that  more  

This  is  shiny!!!!!  

Page 10: Gluecon oauth-03

3)  Cloud  APIs  •  Within  move  towards  SaaS  –  trend  towards  API  access  to  data/services  to  supplement/replace  browser  access  

•  Salesforce.com expects that within the next year – only 1/3 of access will be via browser  

•  APIs  of  PaaS  offerings  allow  the  customer  to  expose  its  own  cloud  services  

•  Clear  trend  for  these  APIs  is  towards  REST  

Page 11: Gluecon oauth-03

Cloud  cures  everything  

Page 12: Gluecon oauth-03

4)  Na+ve  mobile  apps  

Page 13: Gluecon oauth-03

Drivers  

Lack  of  standards  

Cloud  APIs  

Password  an+-­‐paKern  

Na+ve  mobile  Applica+ons  

OAuth  

Page 14: Gluecon oauth-03

OAuth 2.0

•  Defines  authoriza+on  &  authen+ca+on  framework  for  RESTful  APIs  

•  Approaching  final  standardiza+on  in  IETF  •  Applied  to  delegated  authoriza+on  –  mi+gates  password  an+-­‐paKern  -­‐  archetypical  use  case  

•  Also  applicable  to  many  other  scenarios  –  even  those  with  no  users  

•  Notable  for  its  op+miza+ons  for  mobile  

Page 15: Gluecon oauth-03
Page 16: Gluecon oauth-03

Mobile  app  IdM  architecture    

Page 17: Gluecon oauth-03

Na+ve  vs  web  apps  •  Not  going  to  try  to  predict  winner  –  expect  both  •  Authen+ca+on  &  authoriza+on  should  be  consistent  

across  both  models,  so  that  

–  Users  are  not  confused,  eg  use  different  creden+als  and/or  authen+ca+on  ceremony  for  the  two  models,  even  if  accessing  the  same  applica+on  

–  Service  Providers  aren’t  forced  to  implement  duplicate  &  incompa+ble  security  frameworks  for  the  two  models  

Page 18: Gluecon oauth-03

Federa+on  •  Federa+on  abstracts  away  from  applica+ons  specifics  of  authen+ca+on  &  authoriza+on  –  outsourced  to  specialized  providers  

•  Complexity  hidden  by  token  issuance  &  valida+on  •  Federa+on  standards  define  

– Token  formats  

– How  clients  obtain  tokens  – How  clients  present  tokens  to  applica+on  providers    

Page 19: Gluecon oauth-03

Tokens  •  Federated  authen+ca+on  for  both  web  and  

na+ve  mobile  applica+ons  is  based  on  exchange  and  delivery  of  tokens  to  the  applica+on  

•  Tokens  carry  (or  point  to)  security  informa+on  (like  aKributes  or  authoriza+ons)  for  user  trying  to  access  the  applica+on.    

•  Clients  typically  exchange  creden+als  for  tokens  -­‐  easier/safer  to  share  the  token  across  the  network  rather  than  the  original  creden+als  

•  When  token  is  subsequently  presented  to  an  applica+on  provider,  they  serve  to  authen+cate  and/or  authorize  the  request  

Page 20: Gluecon oauth-03

Federa+on  takes  different  forms  

app  

data  

AKributes  for  authen+ca+on  

Authoriza+on  for  aKributes  

For  web  apps,  tokens  carry  

For  na+ve  apps,  tokens  carry  

app  

Browser  

Page 21: Gluecon oauth-03

Tokens  for  mobile  web  applica+ons  •  Federa+on  for  web  applica+ons  manifests  as  SSO  from  some  IdP  to  the  applica+on  provider  

•  SSO  especially  relevant  for  mobile  

•  Tokens  aKes+ng  to  the  user’s  iden+ty  and/or  authen+ca+on  status  delivered  through  (as  redirects)  the  browser  from  IdP  to  the  applica+on  provider  

•  Applica+on  provider  validates  token  and  extracts  iden+ty  aKributes  from  within  in  order  to  create  local  session    

Page 22: Gluecon oauth-03

Tokens  for  web  applica+ons  

Iden+ty  provider   Service  provider  

Device   Browser  

Pwd   HTML  

1.  User  trades  creden+als  for  a  token  from  IdP  

2.  Token  delivered  through  the  browser  to  SP  

3.  SP  validates  token,  and  delivers  applica+on  HTML  to  browser  

Token  

SAML  OpenID   Applica+on  

Page 23: Gluecon oauth-03

Best  prac+ces  •  Standards  

–  OpenID  2.0  for  consumer  scenarios  –  SAML  2.0  for  enterprise  &  cloud  – WS-­‐Federa+on  for  homogeneous  MSFT  

•  IdP  Discovery  –  In  consumer  space,  consider  Nascar  with  email-­‐based  supplement  

–  In  cloud  space,  consider  email-­‐based  •  Both  IdP  (portal)  and  SP  (deep-­‐linking)  ini+ated  are  relevant  

•  Mobile  browser  constraints  may  recommend  ar+fact  model  in  SAML  

Page 24: Gluecon oauth-03

Tokens  for  na+ve  applica+ons  

•  Na+ve  applica+ons  authen+cate  to  REST  APIs  by  presen+ng  a  token  on  the  call  

•  The  precursor  act  of  the  na+ve  applica+on  obtaining  a  token  is  oeen  called  ‘authoriza+on’  (par+cularly  in  those  cases  when  the  API  fronts  user  info,  eg  profile,  tweets,  etc)  

•  User  authorizes  (or  consents)  to  the  na+ve  applica+on  having  access  to  the  API  (and  their  data)  –  the  authoriza+on  is  manifested  as  the  issuance  of  a  token  to  the  na+ve  app  

•  OAuth  2.0  dominant  protocol  by  which  a  na+ve  app  obtains  the  desired  authoriza+ons  and  the  corresponding  token  (and  then  uses  against  API)  

Page 25: Gluecon oauth-03

Mobile  authn  op+ons  

Inline  

External  browser  

Embedded  browser   • Pwd  shared  with  3rd  party  • App  owns  UI  

• Visual  trust  cues  • Can  leverage  stored  pwds  

• No  need  to  leave  app  

• Custom  scheme  • Enables  SSO  • Enables  strong  authn  • AS  owns  UI  

Page 26: Gluecon oauth-03

Tokens  for  na+ve  applica+ons  Service  provider  

Device  

Browser  

Applica+on  

Token  Pwd  JSON/XML  

1.  User  trades  creden+als  for  a  token  2.  Token  delivered  through  the  browser  

to  na+ve  applica+on  3.  Na+ve  applica+on  presents  token  on  

API  calls  4.  Applica+on  returns  applica+on  data  

as  JSON  

OAuth  

Applica+on  

Page 27: Gluecon oauth-03

Best  prac+ces  •  Use  the  browser  to  authen+cate  the  user  to  the  AS,  

don’t  collect  user  passwords  within  na+ve  applica+on  itself  

•  A  separate  browser  window  preferred  to  embedded  –  gives  user  the  visual  trust  cues  trained  to  look  for  

•  OAuth  authoriza+on  code  grant  type  is  relevant  –  allows  a  refresh  token  to  be  delivered  to  the  na+ve  applica+on  (obviates  need  to  con+nually  reauthorize)  

•  Use  browser  for  IdP  discovery  if  doing  SSO  (rather  than  within  na+ve  applica+on  itself)  

•  Na+ve  applica+on  should  register  custom  scheme  on  install,  to  enable  subsequent  passing    of  token  from  browser  back  to  na+ve  applica+on  

Page 28: Gluecon oauth-03

Walk  through  

•  Walk  through  scenario  of  an  employee  using  a  na+ve  app  on  their  phone/tablet  to  interact  with  a  SaaS  provider  

•  SAML  provides  – Authen+ca+on  of  employee  to  SaaS  provider  

•  OAuth  provides  – authoriza+on  of  na+ve  app  to  access  SaaS  APIs  –  Issuance  of  tokens  from  SaaS  to  na+ve  app  

Page 29: Gluecon oauth-03

Walk  through  

                                                                                                         SAML  

                                                                                                                                             OAuth  

                                                                                                                   OAuth  

Page 30: Gluecon oauth-03

Load  authz  page  

Page 31: Gluecon oauth-03

Load  authz  page  

Page 32: Gluecon oauth-03

Load  authz  page  GET  /as/authoriza+on.oauth2?client_id=mobileapp&state=abc123&redirect_uri=mobileapp://redirect_here&response_type=code  HTTP/1.1  

Note  -­‐ -­‐  No  client  pwd  -­‐ -­‐  custom  scheme  on  redirect  URL  -­‐ -­‐  response  type  of  ‘code’  

Page 33: Gluecon oauth-03

IdP  Discovery  

Page 34: Gluecon oauth-03

IdP  Discovery  

Page 35: Gluecon oauth-03

IdP  discovery  

Page 36: Gluecon oauth-03

SSO  Request  

Page 37: Gluecon oauth-03

SSO  request  

Page 38: Gluecon oauth-03

SSO  Request  

<samlp:AuthnRequest    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml="urn:oasis:names:tc:SAML:2.0:asser+on"  ID="aaf23196-­‐1773-­‐2113-­‐474a-­‐fe114412ab72"  Version="2.0"  IssueInstant="2004-­‐12-­‐05T09:21:59Z”>  

   <saml:Issuer>hKps://sp.example.com/SAML2</saml:Issuer>    <samlp:NameIDPolicy  AllowCreate="true"    Format="urn:oasis:names:tc:SAML:2.0:nameid:format:persistent"/>  

</samlp:AuthnRequest>  

<form  method="post"  ac+on="hKps://idp.example.org/SAML2/SSO/POST"  >  <input  type="hidden"  name="SAMLRequest"  value="request"  />  <input  type="submit"  value="Submit"  />  </form>    

Page 39: Gluecon oauth-03

User  authen+ca+on  

Page 40: Gluecon oauth-03

User  authen+ca+on  

Page 41: Gluecon oauth-03

User  authen+ca+on  

Page 42: Gluecon oauth-03

SSO  response  

Page 43: Gluecon oauth-03

SSO  Response  

Page 44: Gluecon oauth-03

SSO  Response  <saml:Asser+on>  <saml:Issuer>hKps://idp.example.org/SAML2</saml:Issuer>  

<ds:Signature  xmlns:ds="hKp://www.w3.org/2000/09/xmldsig#">...</ds:Signature>  

<saml:Subject>  <saml:NameID  Format="urn:oasis:names:tc:SAML:2.0:nameid-­‐format:persistent">  3f7b3dcf-­‐1674-­‐4ecd-­‐92c8-­‐1544f346baf8  </saml:NameID></saml:Subject>  

<saml:AKributeStatement>  

<saml:AKribute  Name=“email”  >  

<saml:AKributeValue  xsi:type="xs:string">pmadsen@pingiden+ty.com</saml:AKributeValue>    

</saml:AKribute>    

</saml:AKributeStatement>    

</saml:Asser+on>    

Page 45: Gluecon oauth-03

Response  with  code  

Page 46: Gluecon oauth-03

Response  with  code  

Page 47: Gluecon oauth-03

Response  with  code  HTTP/1.1  302  Found  Loca+on:  mobileapp://redirect_here?  

 state=abc123&  

 code=wizJmaSTPAf0wqSeB3vmDx2mNSZK6g  

Content-­‐Length:  0  

Page 48: Gluecon oauth-03

Trade  code  for  token  

Page 49: Gluecon oauth-03

Trade  code  for  token  

Page 50: Gluecon oauth-03

Trade  code  for  token  GET  /as/token.oauth2?client_id=a&redirect_uri=mobileapp://

redirecthere&grant_type=authoriza+on_code&code=wizJmaSTPAf0wqSeB3vmDx2mNSZK6g  HTTP/1.1  

Host:  as.com  

Accept:  */*  

HTTP/1.1  200  OK  Content-­‐Type:  applica+on/json;  charset=UTF-­‐8  

{"token_type":"Bearer","expires_in":"60","refresh_token":"oQWqwMUIL2ndeMHsWEyFO0GyalvKSvc2QI4YuG82RMGkM","access_token":"lSBbci4Jg8MsjiSqZLBrzEXgd4mKUNhOkyF"}  

Page 51: Gluecon oauth-03

Client  calls  API  

Page 52: Gluecon oauth-03

Client  calls  API  

Page 53: Gluecon oauth-03

Client  calls  API  hKps://graph.facebook.com/paul.e.madsen/

friends/?access_token=lSBbci4Jg8MsjiSqZLBrzEXgd4mKUNhOkyF  

Page 54: Gluecon oauth-03

Verify  token  

Page 55: Gluecon oauth-03

Verify  token  

Page 56: Gluecon oauth-03

Verify  token  GET  /as/token.oauth2?

client_id=b&client_secret=pwd&grant_type=urn:ping:validate&token=lSBbci4Jg8MsjiSqZLBrzEXgd4mKUNhOkyF  HTTP/1.1  

Host:  as.com  

Accept:  */*  

 HTTP/1.1  200  OK  Content-­‐Type:  applica+on/json;  charset=UTF-­‐8    

Not  OAuth  defined  

Page 57: Gluecon oauth-03

Return  Data  

Page 58: Gluecon oauth-03

Return  Data  

Page 59: Gluecon oauth-03

Return  data  

HTTP/1.1  200  OK  Content-­‐Type:  applica+on/json;  charset=UTF-­‐8  

Page 60: Gluecon oauth-03

Time  passes  

Page 61: Gluecon oauth-03

Refresh  token  

Page 62: Gluecon oauth-03

Refresh  token  

Page 63: Gluecon oauth-03

Refresh  token  GET  /as/token.oauth2?

client_id=a&grant_type=refresh_token&refresh_token=oQWqwMUIL2ndeMHsWEyFO0GyalvKSvc2QI4YuG82RMGkM  HTTP/1.1  

Host:  localhost:9031  

Accept:  */*  

HTTP/1.1  200  OK  

Content-­‐Type:  applica+on/json;  charset=UTF-­‐8  

{"token_type":"Bearer","expires_in":"60","refresh_token":"JZ7Qa4yH5C8E3CikvcZZsd4ZLUgVyYnieXqybAFjObQpz","access_token":"49BPI5LuNM310o7hbB9m9cIzImT5M8gcRjE"}  

Page 64: Gluecon oauth-03

Thanks  

Paul  Madsen  

@paulmadsen