Securing  your  APIs  with  OAuth,   OpenID,  and  OpenID  Connect          Manish  Pandit   Silicon  Valley  Code  Camp  2015   

About  me     Manish  Pandit   Capital  One,  San  Francisco   @lobster1234     linkedin.com/in/mpandit     slideshare.net/lobster1234     

7  years  at  #svcc     OAuth   Social  PlaMorms   PlayFramework!  Java  –  REST  APIs   MongoDB   Introducing  Scala   PlayFramework!  Scala  –  REST  APIs   API  AnUpaVers   

APIs   Have  always  been  around     Medium  of  informaUon  exchange     RESTful,  SOAP,  Custom     May  carry  sensi%ve  data  over  the  wire     Can  be  called  on  behalf  of  a  user         

API  Security   ThroVling   DoS  ProtecUon   XSS   InjecUons   Access  Control   Transport  Level  Security   IdenUty     

API  Security   ThroVling   DoS  ProtecUon   XSS   InjecUons   Access  Control   Transport  Level  Security   IdenUty     

Access  Control     Who  can  get  in     Whose  data  they  can  access     What  can  they  access     For  how  long   

Typical  Scenario     Online  photo  sharing  website     Allows  users  to  upload  pictures     The  pictures  can  be  flagged  as  private,  or  public     Users  log  in  to  the  website  using  userId/password     The  users  want  to  import  these  pictures  into  their  Facebook     

IoT  –  More  players     Fitness  site  tracks  the  number  of  steps  you  take     The  site  also  allows  you  to  track  your  calories  via  a  food  log     Fitness  site  uses  a  NutriUon  website  to  get  calorie  counts     The  user  can  share  his  steps  on  a  Rewards  site,  which  rewards   the  user  based  on  the  steps.     Rewards  site  does  not  care  about  his  food  intake       

RESTful  APIs  -­‐  Public     /news     /popular   

RESTful  APIs  –  ConfidenUal  ?     /user/12345/status     /photos/12345   

Old  Fashioned  Way     Fitness  Site    imports  NutriUon  site’s  database  nightly     Rewards  site  stores  the  users’  credenUals  for  Fitness  Site  in  it’s   database  to  access  their  data     Rewards  site  imports  Fitness  Site’s  data  nightly  for  all  mutual   users     

Constraints     Fitness  Site    imports  Nutri/on  site’s  database  nightly     Not  real  Ume   Server-­‐to-­‐server  call   Needs  to  idenUfy  itself  in  order  to  access  data   NutriUon  site  may  want  to  rate-­‐limit  it’s  data  access   There  is  no  idenUty  or  user  associated  with  the  nutriUon  catalog   

Constraints     Rewards  site  stores  the  users’  creden/als  for  Fitness  Site  in  it’s   database  to  access  their  data     Rewards  site  can  use  the  Fitness  Site’s  credenUals  to  access  any   data  it  wants  on  the  users’  behalf   In  the  event  of  Rewards  site  geeng  compromised,  the  users  of   Fitness  site  risk  their  credenUals  leaked   Other  than  the  credenUals,  the  Rewards  site  does  not  know  the   idenUty  of  the  user   

Constraints     Rewards  site  imports  Fitness  Site’s  data  nightly  for  all  mutual   users     Not  real  Ume   Rewards  site  needs  to  idenUfy  mutual  users   

Access  PaVerns   Have  the  Fitness  site  idenUfy  itself  to  the  NutriUon  site     Have  the  Rewards  site  idenUfy  itself  to  the  Fitness  site     Have  the  Rewards  site  users  idenUfy  themselves  to  the  Fitness   site     Have  these  users  grant  or  deny  access  to  finer  grained  data  afer   authenUcaUon   

Delegated  AuthenUcaUon     A  (much!)  safer  alternaUve  to  storing  user/password  for  another   site  in  your  database     AuthenUcate  the  user  on  the  site  that  has  both,  his  idenUty  and   his  data     MulUple  idenUUes  –  One  on  Rewards  site,  Another  on  Fitness   site   

Delegated  AuthenUcaUon     Authorize  a  service  to  finer  grained  data     The  Fitness  site  user  can  choose  to  grant  access  to  his  steps  to   the  Rewards  site,  not  his  food  log.   

Challenges     AuthenUcaUon  at  the  source  of  IdenUty     MulUple  User  IdenUUes     MulUple  applicaUon  or  website  idenUUes     AuthorizaUon,  or  limiUng  the  data  access  at  the  users’  will   

DecomposiUon  -­‐  AuthenUcaUon   User  has  credenUals  for  the  Fitness  website     User  has  separate  credenUals  for  the  Rewards  site     User  has  no  idea  about  the  NutriUon  site,  but  the  Fitness  site   does   

DecomposiUon  -­‐  AuthorizaUon   User  can  only  access  his  data  on  the  Fitness  site     Fitness  site  can  access  enUre  NutriUon  Catalog  from  the   NutriUon  site     Rewards  site  can  only  access  steps  for  a  user  on  the  Fitness  site,   and  not  his  food  log   

DecomposiUon  -­‐  IdenUty   Fitness  Site    is  an  idenUty  provider   (for  users)     Rewards  site  is  an  idenUty  provider   (for  users)     NutriUon  site  is  an  idenUty  provider   (for  other  sites  that  pull  its  catalog)   

OAuth     A  protocol  to  allow  for       AuthenUcaUng  the  sites  requesUng  data     DelegaUng  user’s  authenUcaUon  to  the  idenUty  provider     Followed  by  subsequent  authorizaUon     Relies  on  transport  layer  security  for  on-­‐wire  (2.0)   

Resource  Owner       A  user  with  data  on  a  (Resource)  server       (Steps  on  fitbit,  Photos  on  Flickr,  Status  updates  on  Facebook,   Tweets  on  TwiVer)   

Resource       Data  on  the  Resource  Server  belonging  to  a  user       (Fitbit  steps,  Flickr  photos,  Facebook  updates,  TwiVer  tweets)   

Resource  Server       The  server  that  stores  users’  data     (Fitbit,  Flickr,  Facebook,  TwiVer)   

AuthorizaUon  Server       The  server  that  can  assert  users’  credenUals     Usually  same  as  the  Resource  Server  (OpenID  teaser!)     (Fitbit,  Flickr,  Facebook,  TwiVer)   

Client       Any  applicaUon*  trying  to  access  resources  on  the  resource   server  on  a  resource  owner’s  behalf     (Fitbit,  Flickr,  Facebook,  TwiVer)         *  A  client  can  be  a  resource  server  of  its  own,  and  vice  versa     

Access  Tokens     A  proxy  arUfact  for  user  credenUals     Bearer  tokens     A  result  of  an  authorizaUon  step     access_tokens  allow  clients  to  access  a  resource  owner’s  data     access_tokens  expire  afer  a  period  of  Ume     access_tokens  can  be  re-­‐issued   

Refresh  Tokens       Used  to  re-­‐request  access_tokens     Have  a  very  long  expiraUon  compared  to  access_tokens     Not    bearer  tokens   

OAuth  CredenUals       client_id     client_secret     redirect_uri     These  credenUals  are  set  up  during  client  registraUon  with  the   provider   

OAuth  Scopes     Defined  by  the  API  Provider     Can  be  cross  cueng  –  Read/Write/Update/Delete   Can  be  grouped  by  feature  –  steps,  rewards   Can  be  combined  –  Read  steps,  Write  steps   

OAuth  Grants           Flows  or  Use  Cases     

Client  CredenUals  Grant       Solves  for  the  server-­‐to-­‐server  calls     hVps://api.example.com/token?          grant_type=client_credenUals&          client_id=CLIENT_ID&          client_secret=CLIENT_SECRET   

Client  CredenUals  Grant     No  redirect_uri     No  selecUve  granUng  of  scopes     There  is  no  resource  owner,  or  idenUty  involved     Simple  flow,  used  for  server  to  server  calls  via  shared  credenUals     Also  known  as  2-­‐legged  OAuth   

Password  Grant       Client  credenUals  and  resource  owner  credenUals  are  used   together  to  get  access  token     hVps://api.example.com/token?          grant_type=password&          username=USERNAME&          password=PASSWORD&          client_id=CLIENT_ID     

Password  Grant     Used  for  trusted,  naUve  mobile  apps     No  redirect_uri     No  selecUve  granUng  of  scopes     The  resource  owners’  credenUals  are  captured  by  the  client     The  container  (app)  should  be  guaranteed  to  be  secure  in  order   to  store  resource  owner  credenUals   

AuthorizaUon  Code  Grant       Delegated  authenUcaUon  –  the  resource  owner  is  redirected  to   the  idenUty/resource  server  for  authorizaUon,  followed  by  token   exchange     hVps://api.example.com/token?          grant_type=authorizaUon_code&          code=AUTH_CODE_HERE&          redirect_uri=REDIRECT_URI&          client_id=CLIENT_ID&          client_secret=CLIENT_SECRET   

AuthorizaUon  Code  Grant     Resource  Owner  is  sent  to  an  authorizaUon_url  with  client_id  and   redirect_uri     Resource  owner  logs  into  the  Resource  Server       Resource  owner  authorizes  the  client  by  granUng  access     Resource  Server  calls  back  the  client  on  a  redirect_uri  with  a  code     The  client  exchanges  this  code  for  an  access_token  and  a   refresh_token  using  the  client_id  and  client_secret     

AuthorizaUon  Code  Grant     A  true,  delegated  authenUcaUon     Client  and  Resource  Owner  credenUals  are  asserted  separately     Client  has  to  be  a  server  or  service  (not  browser)     Also  called  3-­‐legged  Oauth     Always  has  a  UX   

Implicit  Grant   Resource  Owner  is  sent  to  an  authorizaUon_url  with  client_id   and  redirect_uri     The  client  is  a  browser  or  mobile,  so  no  client_secret.       The  callback_uri  is  a  javascript  callback     Not  a  2-­‐step  process  like  AuthorizaUon  Code     Lesser  used  grant     

AuthorizaUon  Code  Grant     Resource  Owner  is  sent  to  an  authorizaUon_url  with  client_id     Resource  owner  logs  into  the  Resource  Server       Resource  owner  authorizes  the  client  by  granUng  access     Resource  Server  calls  back  on  the  redirect_uri  with  access_token   as  a  hash  URL  parameter   

OAuth  and  IdenUty         Blurry  lines   

OpenID       A  way  to  consolidate  idenUty  by  having  portable  idenUUes     AuthenUcaUon  Protocol     Large  idenUty  providers,  eliminaUng  a  need  for  websites  to  have   their  own  idenUty  stores   

OpenID  and  OAuth         OAuth  is  an  authorizaUon  protocol     OpenID  Connect  is  an  authenUcaUon  protocol  built  on  OAuth   (2.0)   

OpenID  1.0  and  2.0     XML-­‐based     Has  a  disconnect  with  API  world     Low  adopUon   

OpenID  Connect     Third  revision  of  OpenID     Based  on  OAuth  2.0     Much  wider  adopUon     JSON  Based     Interoperable  with  APIs     OAuth  2.0  +  IdenUty  =  OpenID  Connect   

OpenID  Connect     IdenUty  as  an  Oauth  2.0  scope     Allows  for  finer  grained  access  to  user  aVributes  (claims)     Provides  an  endpoint  to  get  those  aVributes     Relies  on  JWS  (JSON  Web  Signature)  for  crypto     Relies  on  JWT  (JSON  Web  Token)  to  represent  claims     

OpenID  Connect  Default  Scopes     openid     profile     email     address     phone     

OpenID  Connect  Claims     Claims  are  finer  grained  aVributes  within  the  scopes     They  can  be  individually  access-­‐controlled  during  the   authenUcaUon  process     email  scope  –  email,  email_verified     profile  scope  –  name,  family  name,  given  name,  gender   

OpenID  Connect  ParUes       RP  or  Relying  Party  is  the  one  which  is  requesUng  idenUty     IDP  or  IdenUty  Provider  is  the  one  which  is  asserUng  idenUty       

OIDC  Response       Returned  afer  authenUcaUon  step     JWT  standard  (JSON  Web  Token)     Contains  metadata  like  issue  date,  expiraUon,  nonce  along  side   id_token     Can  be  encrypted  via  JWS  (JSON  Web  Signature)     Also  contains  an  access_token  that  can  be  used  for  calling  userinfo       

A  JWT   {      "id_token":  "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc          yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5          NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ          fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz          AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q          Jp6IcmD3HP99Obi1PRs-­‐cwh3LO-­‐p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ          NqeGpe-­‐gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd          QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS          K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4          XUVrWOLrLl0nx7RkKU8NXNHq-­‐rvKMzqg"      "access_token":  ”some_token",      "token_type":  "Bearer",      "expires_in":  3600,   }   

userinfo         A  userinfo  endpoint  is  accessed  via  an  OIDC  access  token  that  is   returned  as  a  result  of  authenUcaUon     This  call  returns  the  claims  from  the  user’s  profile  that  the  user   has  consented  to   

OAuth  and  OpenID  Connect     The  authorizaUon  URL  is  configured  as  a  RP  to  an  OIDC  compliant  IDP     The  user  authenUcates,  resulUng  in  a  JWT  with  id_token  and  an   access_token     The  JWT  is  exchanged  for  an  access_token  or  a  authorizaUon  code     based  on  the  oauth  grant     The  access_token  can  be  then  used  to  invoke  /userinfo  when  needed   

      QuesUons?                                      @lobster1234            linkedin.com/in/mpandit