11:57 a.m.
Verkar som mitt tidigare svar inte kommit till listan, försöker igen:
(tl;dr: Johan har hittat det viktigaste stycket, se hans mail.)
Hej Magnus,
Jag ska försöka adressera dina funderingar angående spec-compliance:
OpenID Connect fungerar i vanliga fall (för autentisering på webben, som är det vanligast
use case’t i dagsläget) såhär:
1. Användaren surfar till rp.example.com och klickar på logga in
2. RP’n gör ett authentication request genom att redirect’a användaren i webbläsaren
till op.example.com/authenticate
3. Användaren autentiserar sig på något sätt (out-of-band för OIDC spec’en)
4. OP’n skickar ett authentication request genom att redirect’a användaren i
webbläsaren till rp.example.com/redirect_uri
Det viktiga, men osynliga, faktum är att det finns en webbläsare (”user agent” i
specarna) som sköter punkt-till-punkt kommunikationen.
Så på HTTP request nivå händer egentligen följande (lite förenklat/förkortat):
1. GET rp.example.com, sen GET rp.example.com/login
2. RP’n svarar med 302 och en Location header som innehåller OP’s authentication
request ‘authorization_endpoint’, “Location: op.example.com/authenticate?<auth req
params>”
a. Här kommer webbläsaren in och följer redirect’en, GET
op.example.com/authenticate
3. Användaren autentiserar sig (kommer antagligen inkludera lite fler HTTP requests,
men dessa är utanför spec’en)
4. OP’n svarar till slut med en redirect: 302 och en Location header som innehåller
authentication response RP’s redirect_uri: “Location: rp.example.com/redirect_uri?<auth
resp params>”
a. Här kommer webbläsaren in och följer redirect’en, GET
rp.example.com/redirect_uri
Så även i det vanliga webb-flödet av OIDC, måste RP’n vara publikt åtkomlig för HTTP
request till det man publicerar som redirect_uri för att 4a ska fungera.
I grunden är OIDC ett asynkront protokoll på samma sätt SAML; man får *inte* tillbaka
authentication response som ett HTTP response på authentication request’ets HTTP request.
Saken med SE-Leg är att vi inte har någon webbläsare/user agent.
Så vi låter helt enkelt OP’n och RP’n kommunicera direkt med varandra.
Alltså har vi klippt bort både 2a (authentication request ska skickas som en POST till
authorization_endpoint i SE-Leg) och 4a (OP gör GET direkt på redirect_uri i SE-Leg).
Jag ser inget i specen som skulle förhindra detta use case.
Ert förslag är ett litet avsteg från OIDC-flödet eftersom det antar att RP’n är den som
initierar authentication response.
Det är OP’n som gör det, genom att skicka svaret till RP’s redirect_uri.
Först senare i flödet, för token_endpoint och userinfo_endpoint, sker det direkta HTTP
request/response som RP’n initierar.
Hoppas det blev lite klarare.
Vänliga hälsningar,
---
Rebecka Gulliksson
ICT Services and System Development (ITS)
Umeå University
SE-901 87 Umeå, Sweden
rebecka.gulliksson at umu.se
www.its.umu.se
On 30/09/16 10:51, "se-leg-ref on behalf of Johan Lundberg"
<se-leg-ref-bounces at lists.sunet.se on behalf of lundberg at nordu.net> wrote:
Ska börja med att jag också är ny på det här med OIDC men i https://too
ls.ietf.org/html/rfc6749#section-4.1.2 står det ju att:
"If the resource owner grants the access request, the authorization
server issues an authorization code and delivers it to the client by
adding the following parameters to the query component of the
redirection URI"
Där authorization server är OP och client är RP. Jag kan inte heller se
någon annan anledning till att att RPn (enligt spec) måste registrera
en redirect_uri om den inte skulle användas för att initiera
kommunikation från OPn.
Sen tycker jag också att det är en feature att OPn hör av sig till RPn
när resultatet av autentiseringen är klar. Det är betyder att OPn kan
göra extra kontroller av den information användaren och ombudet har
uppgivit (som tar okänt lång tid) innan resultatet skickas till RPn.
Annars måste ju alla RPs polla OPn för uppdateringar för alla pågånde
autentiseringar.