search

stadlar / IST-FUT-FMTH

Creative Commons Attribution 4.0 International
12 stars 19 forks source link

Optional Usage of OAuth2 for PSU Authentication or Authorization (4.3) #9

Closed gudmundurjon closed 4 years ago

gudmundurjon commented 4 years ago

The XS2A API will allow an ASPSP to implement OAuth2 as a support for the authorization of the PSU towards the TPP for the payment initiation and/or account information service. In this case, the TPP will be the client, the PSU the resource owner and the ASPSP will be the resource server in the abstract OAuth2 model.

This specification supports two ways of integrating OAuth2. The first support is an authentication of a PSU in a pre-step, translating this authentication into an access token to be used at the XS2A interface afterward. This usage of OAuth2 will be referred to in this specification as "if OAuth2 has been used as PSU authentication". Further details shall be defined in the documentation of the ASPSP of this XS2A interface.

The second option to integrate OAuth2 is integration as an OAuth2 SCA Approach to be used for authorization of payment initiations and consents. In both services, PIS and AIS, OAuth2 will in this option be used in an integrated way, by using the following steps: [...]

gudmundurjon commented 4 years ago

Styðja bæði pre-step og integration sjá (03. Implementation Guidelines V1.3.4_20190705.pdf, kafli 4.3)

gislikonrad commented 4 years ago

Hægt væri að búa til short-lived token með amr claim value "user", eins og fjallað er um hjá ietf.

Þjónustan gæti assertað þessu claimi og séð þá að það er búið að framkvæma sca. Hægt er svo að invalidate'a tokenið eftir að aðgerðin er framkvæmt.

gudmundurjon commented 4 years ago

Gætirðu líst í skrefum nákvæmlega hvernig þetta væri mögulegt?

gislikonrad commented 4 years ago

Eigum við kannski að enduropna þetta issue, þá? Annars finnst manni það frekar tilgangslaust...

  1. Þjónusta fær inn JWT token.
    • Þetta token inniheldur amr claim með __pwd___ value, sem dæmi.
  2. Þjónustan sér að þetta token er ekki SCA token
    • SCA token er nánast eins og venjuegt token, nema með styttri líftíma og öðru amr claim value, user sem dæmi.
    • Mætti mögulega hafa það þannig að bæði token eru required og SCA token er bara mjög minimalískt
  3. Þjónustan skilar response sem tilgreinir að það þurfi SCA til að framkvæma þessa aðgerð og bendir á IDP þar sem notandi getur auðkennt sig frekar.
    • Þetta gæti vera 401 response með WWW-Authenticate og Location header.
      • Þetta gæti reynst erfitt fyrir clienta sem eru í browser, þar sem browser tekur svoleiðis response og höndlar það sérstaklega.
  4. Notandi auðkennir sig og application fær nýtt token sem inniheldur arm claim með user value
  5. Application kallar aftur á þjónustu með nýja tokeninu
  6. Þjónusta validate'ar token, framkvæmir aðgerð, og sendir á IDP að invalidate'a SCA token
  7. ...
  8. allir glaðir