To  find  out  what  problems  we  have,  tried  to  repeat  of  Web  security  basics  first.    

1

•  It’s  easiest  to  use  “HTTP  Basic  authenAcaAon”  that  most  websites  use.  Used  for  protect  resource.  The  advantage  of  using  this  technology  is  that  nearly  all  clients  and  servers  support  it.  There  is  no  special  processing  required,  as  long  as  the  caller  takes  reasonable  precauAons  to  keep  the  password  secret.  

•  Usernames  and  passwords  also  work  well  for  applicaAon-­‐to-­‐applicaAon  communicaAons.  Username  used  for  caller  idenAficaAon.  The  trick  -­‐  the  password  must  be  stored  securely,  and  if  it’s  being  used  by  a  server,  where  do  you  store  it?    If  you  are  running  an  applicaAon  server  that  uses  a  database,  you  already  have  solved  this  same  problem,  because  the  database  usually  requires  a  password  too.  BeIer  applicaAon  server  plaJorms  include  a  “credenAal  mapper”  that  can  be  used  to  store  such  passwords  relaAvely  securely.  

•  TwiIer  simplifies  things  for  their  users  by  using  usernames  and  passwords  for  API  authenAcaAon.    Every  Ame  a  user  starts  a  TwiIer  client,  it  either  prompts  for  the  username  and  password  to  use,  or  it  fetches  them  from  the  disk  (where  it  is  somehow  scrambled  or  encrypted  where  possible).  So  here  it  makes  a  lot  of  sense  to  have  the  same  username  /  password  for  the  TwiIer  API  that  it  used  for  the  web  site.  

 

2

API  key  used  for  caller  idenAficaAon.  

3

Take  Yahoo  and  Google  maps  –  they  are  fairly  open.    They  want  to  know  who  you  are  but  they  aren’t  concerned  what  address  you  are  looking  up.  API  key  idenAfy  the  caller.    The  API  key  lets  them  idenAfy  (most  likely)  who  is  making  a  API  call  so  they  can  limit  on  the  number  of  requests  you  can  make.  IdenAty  is  important  here  to  keep  service  volume  under  control.  An  API  key  gives  the  API  provider  a  way  to  (most  of  the  Ame)  know  the  idenAty  of  each  caller  to  maintain  a  log  and  establish  quotas  by  user  (see  the  last  secAon).      Check  IP  addresses  of  caller  (legacy)  is  analog  of  IP  check  during  Basic  Authen:ca:on.    

4

Large  service  providers  offer  user-­‐friendly  interfaces  to  work  with  the  public  API  

5

Usually  public  site  provide  console  for  API-­‐Key  generaAon  

6

So  they  use  an  “API  key”  to  establish  idenAty,  but  don’t  authenAcate  or  authorize.    So  if  you  use  someone  else’s  API  key,  it’s  not  good  but  not  a  serious  security  breach.  

7

For  future  purpose  we  introduce  term  -­‐  Nonce  

8

Key  authenAcaAon  is  the  process  of  assuring  that  the  key  of  "person  A"  held  by  "person  B"  does  in  fact  belong  to  "person  A"  and  vice  versa.  This  is  usually  done  aZer  we  assume  that  the  keys  have  been  shared  among  the  two  sides  over  some  secure  channel,  although  some  of  the  algorithms  share  the  keys  at  the  Ame  of  authenAcaAon  also.    Symmetric  cryptosystems  provides  method  of  encrypAon  in  which  for  encrypAon  and  decrypAon  used  the  same  cryptographic  key.    The  encrypAon  key  must  be  kept  in  secret  by  both  parAes.    In  terms  of  the  OAuth  login  analogue  called  Key,  and  password  analogue  -­‐  Secret.  The  situaAon  when  the  Secret  is  known  only  to  the  sender  and  the  recipient  called  Shared  Secret.    The  weakness  of  this  soluAon  is  possibility  to  calculate  key,  if  you  now  both  unencrypted  text  and  encrypted  text!!!  

9

This  is  the  problem  of  assuring  that  there  is  no  man-­‐in-­‐the-­‐middle  aIacker  who  is  trying  to  read  or  spoof  the  communicaAon.  There  are  various  algorithms  used  now-­‐a-­‐days  to  prevent  such  aIacks.  The  most  common  among  the  algorithms  are  Diffie–Hellman  key  exchange  protocol,  enables  two  or  more  parAes  to  obtain  a  shared  secret  key  using  unprotected  from  listening  communicaAon  channel.  The  resulAng  key  is  used  to  encrypt  further  exchange  using  symmetric  encrypAon  algorithms.  

10

Encrypted  with  one  key  -­‐>  decrypted  with  the  other    A  public  key  infrastructure  (PKI)  is  a  set  of  hardware,  soZware,  people,  policies,  and  procedures  needed  to  create,  manage,  distribute,  use,  store,  and  revoke  digital  cerAficates.  

11

AuthenAcaAon  with  signature  is  secure!  But  we  must  use  Nonce  for  protect  from  replay  aIacks.  Nonce  usually  included  into  signature    Now  you  know  all  required  theory  and  you  are  ready  to  write  your  own  bicycle!!!    Pay  aIenAon  to  the  aIributes  of  the  query:X-­‐API-­‐KEY,  X-­‐SIGNATURE,  X-­‐NONCE.  Non-­‐standart  soluAon.  Every  company  make  own  implementaAon.  Amazon  was  first  (and  probably  the  best)!      

12

hIp://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthenAcaAon.html#ConstrucAngTheAuthenAcaAonHeader    So  custom  secure  soluAon  without  OAuth  is  possible.    But  all  this  soluAons  non-­‐standardized!  You  must  read  manuals  every  Ame  for  a  long  Ame!!!    

13

14

OAuth  was  designed  to  solve  the  applicaAon-­‐to-­‐applicaAon  security  problem.  The  idea  of  OAuth  is  that  it  gives  the  user  of  a  service  or  web  site  a  way  to  condiAonally  grant  access  to  another  applicaAon.  OAuth  makes  it  possible  for  a  human  user  to  individually  grant  other  APIs  or  sites  access  to  their  account  without  sharing  their  actual  password.  It  works  by  giving  a  “token”  to  each  API  or  site  that  will  access  the  account,  which  the  user  may  revoke  at  any  Ame  they  wish.  

15

User:  end-­‐user  of  applicaAon.    Consumer:  applicaAon/form  processing  received  data.    Service  Provider:  data  provider;  such  as  GMail,  providing  access  to  protected  resource.    Protected  Resource:  real  resources  such  as  personal  data  or  contacts  from  your  Gmail  address  book.    Provider  API:  API  GMail,  allows  any  script  to  get  contacts  from  the  address  book  Gmail.    Task  of  OAuth  -­‐  make  User  was  able  to  work  on  the  service  Consumer  with  the  protected  data  provided  by  the  Service  Provider  (Gmail)    OAuth  founda=on  •  App  =  Consumer  +  API  access  •  Token  =  Key  +  Secret          One  of  the  principles  OAuth  states  that  no  secret  keys  should  not  be  passed  in  a  query  open.  Therefore,  the  protocol  uses  the  term  Token.            The  token  is  very  similar  to  a  pair  of  username  +  password  :  login  -­‐  public  informaAon    and  password  -­‐  known  only  to  the  transmilng  and  receiving  side.          In  terms  of  OAuth  login  analogue  called  Key,  and  the  analogue  password  -­‐  Secret.  SituaAon  where  Secret  is  known  only  to  the  sender  and  the  recipient  ,  but  over    

16

Fundamental:  OAuth  =  Fetch  Request  Token  +  Redirect  to  Authoriza=on  +  Fetch  Access  Token  +  Call  API    Steps:  1.  Fetch  Request  Token  (inner  query).  Consumer-­‐script  refers  to  a  Request  token  URL  Provider-­‐as  for  example,  api.rutvit.ru  /  oauth  /  request_token.  The  request  is  transmiIed  Consumer  key  -­‐  «login  applicaAon",  and  the  request  is  signed  using  the  Consumer  secret  -­‐  «applicaAon  password"  which  protects  it  against  forgery.    In  response  Provider  generates  and  returns  a  "filled  with  garbage"  token  called  Request  Token.  It  sAll  is  useful  to  us,  so  we  need  to  keep  it  somewhere  -­‐  for  example,  in  the  session  variable  $  S_REQUEST_TOK.    2.  Redirect  to  Authoriza=on  (via  redirect  the  browser).  Now  that  our  applicaAon  has  a  unique  Request  Token.  Requires  the  user  to  obtain  permission  to  use  this  token,  ie  ask  him  to  authorize  Request  Token.  Consumer  redirects  the  browser  to  a  special  Authorize  Provider  URL    for  example,  api.rutvit.ru  /  oauth  /  authorize.  In  the  parameters  passed  Request  Token  Key.    Provider  displays  the  authorizaAon  form  for  your  user  if  he  is  logged  in,  the  browser  redirects  back.  Where  is  it?  And  we  give  this  parameter  oauth_callback.    

17

3  .  Fetch  Access  Token  (  inner  query  )  .  So,  does  he  returned  to  our  applicaAon  aZer  a  series  of  redirects.  This  means  that  authorizaAon  on  the  Provider  was  successful,  and  Request  Token  is  allowed  to  work.  However,  the  OAuth  token  for  each  security  has  its  own  strictly  limited  purpose.  For  example  ,  Request  Token  is  used  only  to  obtain  confirmaAon  from  the  user,  and  for  anything  else  .  To  access  the  resources  we  need  to  get  a  new  token  -­‐  Access  Token  -­‐  or  as  they  say  ,  “Request  Token  exchange  on  Access  Token».  Consumer  refers  to  Access  token  URL  -­‐  for  example  ,  api.rutvit.ru  /  oauth  /  access_token,  -­‐  and  applies  for  the  Access  Token  him  return  it  available  Request  Token-­‐  a.  Request  digitally  signed  on  the  basis  of  Request  Token  secret.  Provider  generates  and  returns  the  Access  Token,  filled  with  "garbage  ."  He  also  marks  in  their  tables  that  this  Access  Token-­‐  and  allowed  access  to  API.  Our  applicaAon  needs  to  save  at  Access  Token,  if  it  is  going  to  use  the  API  in  the  future.    4.  Call  API  (inner  query).  Well,  now  we  have  the  Access  Token,  and  we  can  pass  it  when  calling  the  key  API.Consumer  generates  a  request  to  the  API  Provider-­‐a  (for  example,  using  the  POST-­‐request  under  REST-­‐ideology).  The  request  is  transmiIed  Access  Token  Key,  and  it  is  signed  using  the  Shared  Secret  that  token.    Provider  processes  the  API-­‐call,  and  returns  the  data  to  the  applicaAon.    

18

Source:  hIp://blog.biIercoder.com/2008/06/10/oauth-­‐for-­‐beginners/      

19

20

1.  ApplicaAon-­‐Consumer  receives  Request  Token.    2.  The  user  is  redirected  to  the  site  of  the  Service  Provider  and  authorizes  there  

Request  Token.    3.  ApplicaAon-­‐Consumer  exchanges  Request  Token  for  Access  Token.    4.  ApplicaAon-­‐Consumer  applicaAon  makes  authenAcated  requests  to  the  API  

service.  

Very  good  security!  If  we  use  verified  secret  key  storage  then  we  got  same  level  of  security  as  xRoadLevel  is    

21

In  reference  to  digital  security,  nonrepudiaAon  means  to  ensure  that  a  transferred  message  has  been  sent  and  received  by  the  parAes  claiming  to  have  sent  and  received  the  message.  NonrepudiaAon  is  a  way  to  guarantee  that  the  sender  of  a  message  cannot  later  deny  having  sent  the  message  and  that  the  recipient  cannot  deny  having  received  the  message.  NonrepudiaAon  can  be  obtained  through  the  use  of:  digital  signatures-­‐-­‐  funcAon  as  a  unique  idenAfier  for  an  individual,  much  like  a  wriIen  signature.  confirmaAon  services  -­‐-­‐  the  message  transfer  agent  can  create  digital  receipts  to  indicated  that  messages  were  sent  and/or  received.  Amestamps  -­‐-­‐  Amestamps  contain  the  date  and  Ame  a  document  was  composed  and  proves  that  a  document  existed  at  a  certain  Ame.    AuthenAcaAon  is  a  technical  concept:  e.g.,  it  can  be  solved  through  cryptography.  Non-­‐repudiaAon  is  a  legal  concept:  e.g.,  it  can  only  be  solved  through  legal  and  social  processes  (possibly  aided  by  technology).    

22

•  OAuth  needs  secret  key.  xRoad  public/private  cerAficates  may  be  used  •  xRoad  store  cerAficates  in  secure  server  (turvaserver),  in  case  of  OAuth  it  may  be  

any  verified  cerAficate  storage,  such  as  LDAP  •  xRoad  organizaAon  and  procedures  are  very  good!!!  •  xRoad  provide  messaging  API  •  xRoad  required  special  soZware  for  secure  server,  Oauth  don’t  require  •  xRoad  is  Estonian  standard,  OAuth  is  internaAonal  standard    OAuth  is  same  secure  and  can  replace  xRoad  in  interna=onal  projects  (NB!  This  is  Igor  Bossenko  personal  posi=on  and  currently  doesn’t  reflect  Nortal  point  of  view!!!)  

23

24

Why  a  New  Version?  OAuth  1.0  was  largely  based  on  two  exisAng  proprietary  protocols:  Flickr’s  API  Auth  and  Google’s  AuthSub.  The  result  represented  the  best  soluAon  based  on  actual  implementaAon  experience.  With  over  3  years  of  experience  working  with  the  protocol,  the  community  learned  enough  to  rethink  and  improve  the  protocol  in  three  main  areas  where  OAuth  1.0  proved  limited  or  confusing    

25

Authen=ca=on  and  Signatures  The  majority  of  failed  OAuth  1.0  implementaAon  aIempts  are  caused  by  the  complexity  of  the  cryptographic  requirements  of  the  specificaAon.  OAuth  1.0  is  sAll  not  trivial  to  use  on  the  client  side.  For  example,  with  the  move  to  OAuth,  developers  are  now  forced  to  find,  install,  and  configure  libraries  in  order  to  accomplish  what  was  before  possible  with  a  single  line  of  cURL  script.  User  Experience  and  Alterna=ve  Token  Issuance  Op=ons  OAuth  includes  two  main  parts:  obtaining  a  token  by  asking  the  user  to  grant  access,  and  using  tokens  to  access  protected  resources.  The  methods  for  obtaining  an  access  token  are  called  flows.  OAuth  1.0  started  out  with  3  flows:  web-­‐based  applicaAons,  desktop  clients,  and  mobile  or  limited  devices.  However,  as  the  specificaAon  evolved,  the  three  flows  were  merged  into  one  which  (on  paper)  enabled  all  three  client  types.  In  pracAce,  the  flow  works  fine  for  web-­‐based  applicaAons  but  provides  an  inferior  experience  elsewhere.  Performance  at  Scale  As  large  providers  started  using  OAuth,  the  community  realized  that  the  protocol  does  not  scale  well.  It  requires  state  management  across  different  steps,  temporary  credenAals  which  are  more  oZen  than  not  discarded  unused,  and  typically  requires  issuing  long  lasAng  credenAals  which  are  less  secure  and  harder  to  manage  (and  synchronize  across  data  centers).  In  addiAon,  OAuth  1.0  requires  that  the  protected  resources  endpoints  have  access    

26

Flows  NaAve  applicaAon  support  (applicaAons  running  on  a  desktop  or  mobile  device)  can  be  implemented  using  many  of  the  flows  above.  Bearer  tokens  OAuth  2.0  provides  a  cryptography-­‐free  opAon  for  authenAcaAon  which  is  based  on  exisAng  cookie  authenAcaAon  architecture.  Instead  of  sending  signed  requests  using  HMAC  and  token  secrets,  the  token  itself  is  used  as  a  secret  sent  over  HTTPS.  This  allows  making  API  calls  using  cURL  and  other  simple  scripAng  tools  without  having  to  canonicalize  the  request  and  sign  it.  Simplified  signatures  Signature  support  has  been  significantly  simplified  to  remove  the  need  for  special  parsing,  encoding,  and  sorAng  of  parameters.  It  also  uses  a  single  secret  instead  of  two.  Short-­‐lived  tokens  with  Long-­‐lived  authoriza=ons  Instead  of  issuing  a  long  lasAng  token  (typically  good  for  a  year  or  unlimited  lifeAme),  the  server  can  issues  a  short-­‐lived  access  token  and  a  long  lived  refresh  token.  This  allows  clients  to  obtain  a  new  access  token  without  having  to  involve  the  user  again,  but  keeps  access  tokens  limited.    Separa=on  of  Roles  OAuth  2.0  separates  the  role  of  the  authorizaAon  server  responsible  for  obtaining  user  authorizaAon  and  issuing  tokens  from  that  of  the  resource  server  handling  API    

27

In  July  2012,  Eran  Hammer  resigned  his  role  of  lead  author  for  the  OAuth  2.0  project,  withdrew  from  the  IETF  working  group,  and  removed  his  name  from  the  specificaAon.  Hammer  pointed  to  a  conflict  between  the  web  and  enterprise  cultures,  ciAng  the  IETF  as  a  community  that  is  "all  about  enterprise  use  cases",  that  is  "not  capable  of  simple."  What  is  now  offered  is  a  blueprint  for  an  authorizaAon  protocol,  he  says,  and  "that  is  the  enterprise  way",  providing  a  "whole  new  fronAer  to  sell  consulAng  services  and  integraAon  soluAons.”  Despite  this,  it  has  been  noted  that  OAuth  2.0  doesn't  fit  enterprise  cultures  either.  Management  is  unlikely  to  want  to  offer  an  external  API  upon  a  framework  which  is  non-­‐interoperable  and  presents  unquanAfiable  risk.  In  comparing  OAuth  2.0  with  1.0,  Hammer  points  out  that  it  has  become  "more  complex,  less  interoperable,  less  useful,  more  incomplete,  and  most  importantly,  less  secure."      

28

29

OAuth2  is  more  infrastructure  than  protocol  6  New  Flows  in  Oauth  2.0  User-­‐Agent  Flow  –  for  clients  running  inside  a  user-­‐agent  (typically  a  web  browser).  Web  Server  Flow  –  for  clients  that  are  part  of  a  web  server  applicaAon,  accessible  via  HTTP  requests.  This  is  a  simpler  version  of  the  flow  provided  by  OAuth  1.0.  Device  Flow  –  suitable  for  clients  execuAng  on  limited  devices,  but  where  the  end-­‐user  has  separate  access  to  a  browser  on  another  computer  or  device.  Username  and  Password  Flow  –  used  in  cases  where  the  user  trusts  the  client  to  handle  its  credenAals  but  it  is  sAll  undesirable  for  the  client  to  store  the  user’s  username  and  password.    This  flow  is  only  suitable  when  there  is  a  high  degree  of  trust  between  the  user  and  the  client.  Client  Creden=als  Flow  –  the  client  uses  its  credenAals  to  obtain  an  access  token.  This  flow  supports  what  is  known  as  the  2-­‐legged  scenario.  Asser=on  Flow  –  the  client  presents  an  asserAon  such  as  a  SAML  asserAon  to  the  authorizaAon  server  in  exchange  for  an  access  token.      

30

The  AuthorizaAon  Code  or  Web  server  flow  is  suitable  for  clients  that  can  interact  with  the  end-­‐user’s  user-­‐agent  (typically  a  Web  browser),  and  that  can  receive  incoming  requests  from  the  authorizaAon  server  (can  act  as  an  HTTP  server).  The  AuthorizaAon  Code  flow  is  as  follows:  1.  The  Web  server  redirects  the  user  to  the  API  Gateway  acAng  as  an  AuthorizaAon  

Server  to  authenAcate  and  authorize  the  server  to  access  data  on  their  behalf.  2.  AZer  the  user  approves  access,  the  Web  server  receives  a  callback  with  an  

authorizaAon  code.  3.  AZer  obtaining  the  authorizaAon  code,  the  Web  server  passes  back  the  

authorizaAon  code  to  obtain  an  access  token  response.  4.  AZer  validaAng  the  authorizaAon  code,  the  API  Gateway  passes  back  a  token  

response  to  the  Web  server.  5.  AZer  the  token  is  granted,  the  Web  server  accesses  their  data.  

hIp://docs.oracle.com/cd/E39820_01/doc.11121/gateway_docs/content/oauth_flows.html    

31

hIps://developers.google.com/accounts/docs/OAuth2WebServer    1.  Scope  -­‐  IdenAfies  the  Google  API  access  that  your  applicaAon  is  requesAng.    Redirect_uri  -­‐  Determines  where  the  response  is  sent.    Client_id  -­‐  IdenAfies  the  client  that  is  making  the  request.    State  –  sender  specific  applicaAon  state  Response_type  =  code  -­‐  Determines  whether  the  Google  OAuth  2.0  endpoint  returns  an  authorizaAon  code  approval_prompt  -­‐  Indicates  whether  the  user  should  be  re-­‐prompted  for  consent.  Default  is  auto.  -­‐-­‐-­‐  3.  Code  -­‐  The  authorizaAon  code  returned  from  the  iniAal  request.  

32

4.    client_secret  -­‐  The  client  secret  obtained  from  the  Developers  Console.    5.    access_token  The  token  that  can  be  sent  to  a  Google  API.  refresh_token  A  token  that  may  be  used  to  obtain  a  new  access  token.  Refresh  tokens  are  valid  unAl  the  user  revokes  access.  This  field  is  only  present  if  access_type=offline  is  included  in  the  authorizaAon  code  request.  expires_in    The  remaining  lifeAme  of  the  access  token.  token_type    IdenAfies  the  type  of  token  returned.  At  this  Ame,  this  field  will  always  have  the  value  Bearer.  

33

The  Implicit  Grant  (User-­‐Agent)  authenAcaAon  flow  is  used  by  client  applicaAons  (consumers)  residing  in  the  user's  device.  This  could  be  implemented  in  a  browser  using  a  scripAng  language  such  as  JavaScript,  or  from  a  mobile  device  or  a  desktop  applicaAon.  These  consumers  cannot  keep  the  client  secret  confidenAal  (applicaAon  password  or  private  key).  The  User  Agent  flow  is  as  follows:  1.  The  Web  server  redirects  the  user  to  the  API  Gateway  acAng  as  an  AuthorizaAon  

Server  to  authenAcate  and  authorize  the  server  to  access  data  on  their  behalf.  2.  AZer  the  user  approves  access,  the  Web  server  receives  a  callback  with  an  access  

token  in  the  fragment  of  the  redirect  URL.  3.  AZer  the  token  is  granted,  the  applicaAon  can  access  the  protected  data  with  the  

access  token.  

35

The  Resource  Owner  password  credenAals  flow  is  also  known  as  the  username-­‐password  authenAcaAon  flow.  This  flow  can  be  used  as  a  replacement  for  an  exisAng  login  when  the  consumer  already  has  the  user’s  credenAals.    The  Resource  Owner  password  credenAals  grant  type  is  suitable  in  cases  where  the  Resource  Owner  has  a  trust  relaAonship  with  the  client  (for  example,  the  device  operaAng  system  or  a  highly  privileged  applicaAon).  The  AuthorizaAon  Server  should  take  special  care  when  enabling  this  grant  type,  and  only  allow  it  when  other  flows  are  not  viable.    This  grant  type  is  suitable  for  clients  capable  of  obtaining  the  Resource  Owner's  credenAals  (username  and  password,  typically  using  an  interacAve  form).  It  is  also  used  to  migrate  exisAng  clients  using  direct  authenAcaAon  schemes  such  as  HTTP  Basic  or  Digest  authenAcaAon  to  OAuth  by  converAng  the  stored  credenAals  to  an  access  token.  

36

The  client  credenAals  grant  type  must  only  be  used  by  confidenAal  clients.  The  client  can  request  an  access  token  using  only  its  client  credenAals  (or  other  supported  means  of  authenAcaAon)  when  the  client  is  requesAng  access  to  the  protected  resources  under  its  control.  The  client  can  also  request  access  to  those  of  another  Resource  Owner  that  has  been  previously  arranged  with  the  AuthorizaAon  Server  (the  method  of  which  is  beyond  the  scope  of  the  specificaAon).  

37

A  JSON  Web  Token  (JWT)  is  a  JSON-­‐based  security  token  encoding  that  enables  idenAty  and  security  informaAon  to  be  shared  across  security  domains.  In  the  OAuth  2.0  JWT  flow,  the  client  applicaAon  is  assumed  to  be  a  confidenAal  client  that  can  store  the  client  applicaAon’s  private  key.  The  X.509  cerAficate  that  matches  the  client’s  private  key  must  be  registered  in  the  API  Manager.  The  API  Gateway  uses  this  cerAficate  to  verify  the  signature  of  the  JWT  claim.      

38

Part  of  infrastructure!  You  do  not  need  to  create  its  own  API!    In  some  cases  a  user  may  wish  to  revoke  access  given  to  an  applicaAon.  An  access  token  can  be  revoked  by  calling  the  API  Gateway  revoke  service  and  providing  the  access  token  to  be  revoked.  A  revoke  token  request  causes  the  removal  of  the  client  permissions  associated  with  the  parAcular  token  to  access  the  end-­‐user's  protected  resources.  POST  /api/oauth/revoke  HTTP/1.1  AuthorizaAon:  Basic  U2FtcGxlQ29uZmlkZW50aW…    You  can  use  the  Token  Info  Service  to  validate  that  an  access  token  issued  by  the  API  Gateway.  A  request  to  the  tokenInfo  service  is  an  HTTP  GET  request  for  informaAon  in  a  specified  OAuth  2.0  access  token.  GET  /api/oauth/tokeninfo  HTTP/1.1  access_token=4eclEUX1N6oVIOoZBbaDTI977S…      

39

OAuth  is  oZen  called  “protocol  for  robots,"  in  contrast  to  OpenID  -­‐  «  protocol  for  users."  Do  not  confuse  them  !  OpenID  -­‐  protocol  for  accelerated  registra=on.  OpenID  enables  the  user  to  enter  a  password  to  get  an  account  on  any  service,  if  it  is  already  registered  somewhere  else  on  the  Internet.  (  And  then  you  can  not  enter  a  password  to  log  on  to  the  service  being  authorized  "somewhere  ."  )  For  example,  if  you  have  an  account  on  Yandex  ,  you  can  "  go  "  with  it  on  any  service  that  supports  OpenID-­‐  authorizaAon.  OAuth  -­‐  protocol  for  authorized  access  to  third-­‐party  API.  OAuth  allows  the  script  to  get  a  Consumer-­‐  limited  API-­‐  party  access  to  the  data  Service  Provider-­‐  and  if  User  gives  good.  Ie  a  means  for  access  to  the  API.    

41

Милицейская  аналогия:  Представьте,  что  вы  —  сотрудник  Уголовного  розыска,  ищущий  концы  в  деле  о  краже  WebMoney  за  1973-­‐й  год.  Договоримся  о  терминах:  OAuth  Consumer:  Уголовный  розыск.  User:  сотрудник  Уголовного  розыска.  Service  Provider:  Картотека  архива  преступлений.    OpenID  методика:  сотрудник  Уголовного  розыска  (User)  приходит  в  Картотеку  (Service  Provider),  предъявляет  на  входе  ксиву  (AuthorizaAon)  и  на  месте  перебирает  карточки  в  поисках  информации.  Oauth  методика:  сотрудник  Уголовного  розыска  (User)  прямо  с  работы  (Consumer)  звонит  в  Картотеку  (Service  Provider).  Он  докладывает  свою  фамилию;  если  его  узнают  (AuthorizaAon),  он  просит  предоставить  список  всех  преступлений  за  1973-­‐й  год  (API  call).  Как  видите,  OpenID  и  OAuth  —  разные  вещи.  OpenID  позволяет  вам  прямо  на  месте  получить  доступ  к  некоторым  ресурсам.  OAuth  обеспечивает  получение  части  информации  с  удаленного  сервиса  через  API.    

42

What  is  OpenID  Connect?  OpenID  Connect  1.0  is  a  simple  idenAty  layer  on  top  of  the  OAuth  2.0  protocol.  It  allows  Clients  to  verify  the  idenAty  of  the  End-­‐User  based  on  the  authenAcaAon  performed  by  an  AuthorizaAon  Server,  as  well  as  to  obtain  basic  profile  informaAon  about  the  End-­‐User  in  an  interoperable  and  REST-­‐like  manner.    

43

How  is  OpenID  Connect  different  than  OpenID  2.0?  OpenID  Connect  performs  many  of  the  same  tasks  as  OpenID  2.0,  but  does  so  in  a  way  that  is  API-­‐friendly,  and  usable  by  naAve  and  mobile  applicaAons.  OpenID  Connect  defines  opAonal  mechanisms  for  robust  signing  and  encrypAon.  Whereas  integraAon  of  OAuth  1.0a  and  OpenID  2.0  required  an  extension,  in  OpenID  Connect,  OAuth  2.0  capabili=es  are  integrated  with  the  protocol  itself.  

44

45

46

More  Oauth  2.0  Flows  to  allow  beIer  support  for  non-­‐browser  based  applicaAons.      OAuth  2.0  no  longer  requires  client  applicaAons  to  have  cryptography.  This  hearkens  back  to  the  old  TwiIer  Auth  API,  which  didn't  require  the  applicaAon  to  HMAC  hash  tokens  and  request  strings.  With  OAuth  2.0,  the  applicaAon  can  make  a  request  using  only  the  issued  token  over  HTTPS.    OAuth  2.0  signatures  are  much  less  complicated.  No  more  special  parsing,  sorAng,  or  encoding.    OAuth  2.0  Access  tokens  are  "short-­‐lived".  Typically,  OAuth  1.0  Access  tokens  could  be  stored  for  a  year  or  more  (TwiIer  never  let  them  expire).  OAuth  2.0  has  the  noAon  of  refresh  tokens.      Finally,  OAuth  2.0  is  meant  to  have  a  clean  separaAon  of  roles  between  the  server  responsible  for  handling  OAuth  requests  and  the  server  handling  user  authorizaAon.      

47

48

49

50