4:56 p.m.
On torsdag 29 september 2016 kl. 13:23:07 CEST Magnus Hoflin wrote:
Hej,
Tack för den uppdaterade dokumentationen,
https://github.com/SUNET/se-leg-docs/blob/master/oidc_flow.md, den har
underlättat mycket för förståelsen!
Vi har huvudsakligen två kommentarer:
Kommentar 1:
Det fattas en/två pilar direkt innan steg 14. Man kan ju inte skicka en
HTTP-response från ingenstans utan det måste ju initieras av en
HTTP-request.
Hej
Steg 14 i diagramet är ett OIDC Authentication Response, det är inte ett HTTP
response. Det levereras till RP:n som en HTTP Request ställd till den
redirect_uri som gäller för RP:n.
Att införa en HTTP-request skulle också lösa det
problem vi
tidigare har lyft, nämligen att man inte vill ha en OP-initierad
backend-kanal till IdPn eftersom en sån kanal skulle bara ställa till med
FW-problem etc. Vi föreslår två nya steg precis innan steg 14, kalla dem
13.8 och 13.9:
- 13.8: Pil "User" -> "RP/IdP": Användaren indikerar mot IdPn
att
han/hon är klar med identifieringen på t.ex. biblioteket. Detta kan bl.a.
ske när användaren "klickar bort" QR-koden på mobilen.
- 13.9: Pil "RP/IdP" -> "OP": IdPn begär ett Authentication
response.
Du har anfört säkerhetsskäl för att inte släppa in HTTP requests från OP:n
till RP:n. Min förståelse av OIDC Authorization flow är att det inte funkar
så.
https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
3.1.2.5. Successful Authentication Response
When using the Authorization Code Flow, the Authorization Response MUST return
the parameters defined in Section 4.1.2 of OAuth 2.0 [RFC6749] by adding them
as query parameters to the redirect_uri ...
Det borde vara fullt möjligt för dig att bygga en egen kö-nod utanför din
brandvägg som tar emot dessa svar från OP till RP och sedan låter dig polla
svaren från innanför din brandvägg. Jag säger inte att jag tycker det verkar
vara en bra idé, men givet dina prioriteringar så kanske det är den bästa
lösningen.
Kommentar 2:
Har vi förstått det rätt att det 'nonce' som IdPn genererar i steg 4 är
samma 'nonce' som också används som QR-kod? Hela den här processen kan
sägas baseras på en identifieringstransaktion som OPn ansvarar för. Vi
tycker det känns avigt att IdPn ska generera transaktionsIDt (idag
"noncet") för den transaktion som OPn ansvarar för. Vi förelår att *OPn*
genererar ett 'transaktionsID' som returneras i steg 5 och som sen används
i QR-koden. Detta transaktionsID skickas med i steg 13.8 och 13.9 ovan, så
att OPn vet vilken transaktion den ska returnera identiteten för. Detta är
möjligt p.g.a. att användaren är inloggad via steg 1-2.
Om man fortfarande vill använda ett nonce i det syfte specen anger, dvs som
skydd mot replay-attacker, så kan man förstås göra det också. Men
transaktionsIDt bör inte blandas ihop med replay-skydd-noncet.
Och om det är vi som har feltolkat flödet så är det nog bra om ni
uppdaterar så att det inte heter nonce på båda ställena.
Dessutom:
Om ni vill förtydliga ert sekvensdiagram ytterligare så vore det jättebra
ifall ni kopplade de olika stegen mot de steg som är listade i kapitel
3.1.1 i OpenID-specen.
Tack för synpunkterna.
/Fredrik