Alternative Authentication Flow

[jaxoncreed]

This is based on an offline discussion between @acoburn, @dmitrizagidulin, and @jaxoncreed. TLDR, it's an authentication flow that does not require token wrapping or crypto on the client. Instead, it depends on making a round trip to the OP every time the client wants to query a new RS.

The current WebID-OIDC spec uses PoP with a wrapped id_token, to a large extent because this allows the RP to scope an audience claim to a particular RS (thus addressing the issue of token exfiltration). Per OIDC, the audience claim of an ID token is the RP itself, so this mechanism allows us to direct that audience claim to a particular RS instead.

But if we are changing from using ID tokens to access tokens, we potentially have much more flexibility around the structure of those JWTs. What if, in addition to the standard ID token returned from the /token endpoint of an AS, the response contained an access token with this structure:

{
    "kid" : "AS key id"
}
.
{
    "sub" : "WebID of agent" ,
    "iss" : "AS/IdP identifier" ,
    "aud" : "RS/Pod identifier" ,
    "azp" : "RP/App identifier" ,
    "iat" : "..." ,
    "exp" : "..."
}
.
(AS-based-signature the above)

This would vastly simplify the token structure that an RS needs to validate and it eliminates the need for RPs to sign the outer envelope token. The downside is that, for each RS that a given RP interacts with, that RP would need an extra round-trip with the AS: either via the /token endpoint or some other endpoint where the RP could exchange an ID token for a signed, RS-scoped access token.

[elf-pavlik]

I was thinking about something similar plus including by value or reference authorizations which this Authorization Server considers relevant for specific Resource Server.

I wouldn't worry that much about extra round trips to AS, especially having HTTP/2 available.

The current WebID-OIDC spec uses PoP with a wrapped id_token, to a large extent because this allows the RP to scope an audience claim to a particular RS (thus addressing the issue of token exfiltration).

I think using Sender Constrained tokens like PoP/DPoP already prevents any other client to use that token. I would still see need to request a token per RS since this way we would not leak any client authorizations not relevant for that specific RS. Any location specific authorizations eg. ldp resources hosted on acme.example should not get included (by value or reference) when making requests to yoyodyne.example.

[jaxoncreed]

At least for the purposes of the December draft spec, we will not be doing this authentication flow for 2 reasons:

1. Round trips to the API are still more overhead even if small
2. It would be easier to steal a token under this method as the RP would be constantly exchanging tokens with the AS rather than just keeping a private key stored at rest.

[elf-pavlik]

It would be easier to steal a token under this method as the RP would be constantly exchanging tokens with the AS rather than just keeping a private key stored at rest.

As long as requesting those tokens happen on the back channel it sounds comparable to exchanging refresh token for access token.

Round trips to the API are still more overhead even if small

Current WebID-OIDC doesn't address authorizing clients, I think we need to compare flow discussed in this issue with something that does address authorizing clients while respecting user's privacy.

[elf-pavlik]

@jaxoncreed would you still like to pursuit this approach?

[acoburn]

The current state of the specification answers the issue raised here: https://solid.github.io/authentication-panel/solid-oidc/#resource-access-validation