Re: Authentication draft: difference between dpop-bound access token and oidc id token

Hi,
This is a good question. In your message you noted that the two tokens have
a different aud (audience) claim, which is crucial here.

Under OIDC, an ID token is for use by a client application. That client
application may use that token to determine the user's name, profile image,
etc. The OIDC specification requires that this token be structured as a JWT
so that a client can rely on a single mechanism for parsing/validating that
token. Notably, the aud (audience) claim in an ID token is the client_id.
In other words, an ID token is for the client and should not be used
elsewhere. And an ID token should *definitely not* be used for resource
access.

The access token, on the other hand, is for use with a resource server. A
client application should treat an access token as opaque (even though,
under Solid, it is structured as a JWT). Here the aud (audience) claim is
"solid" which indicates that the token can be used with a Solid resource
server.

I hope that answers your question.

-Aaron



On Tue, 6 Oct 2020 at 06:04, Michiel de Jong <michiel@unhosted.org> wrote:

> Good question!
> Isn't the id token used by the client to create the Authorization header?
>
> I created a github issue pointing to this ML thread, here:
> https://github.com/solid/authentication-panel/issues/78
>
> Cheers,
> Michiel.
>
> On Tue, Oct 6, 2020 at 11:47 AM divoplade <d@divoplade.fr> wrote:
>
>> Dear authentication panel,
>>
>> I am working on implementing the draft at
>>
>> https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md
>> (for the GNU Guile software ecosystem).
>>
>> In the DPoP draft, two objects are mentioned:
>> 1. The DPoP proof, containing fields such as htu and htm, signed by an
>> ad-hoc key present in the JWT header ;
>> 2. The access token, signed by the identity provider, containing
>> traditional oidc token fields such as sub, iss, aud, and most
>> importantly the cnf field to confirm the ad-hoc key used in the proof.
>>
>> The authentication panel draft mentions two objects that are returned
>> by the identity provider to the client:
>> a. The access token, which is the same as the DPoP bound access token
>> (see 2.);
>> b. An OIDC ID token, which looks suspiciously similar but does not use
>> the jkt header and has a different aud clause.
>>
>> Both a. and b. are signed by the identity provider.
>>
>> Is b. maintained here for backwards compatibility? The only difference
>> I see is the meaning of the audience (aud) clause. If so, why ignore it
>> in the following section, Resource Access?
>>
>> If I understand correctly, the Resource Access section should read in
>> its introduction that the Resource server receives a dpop-bound access
>> token + a dpop proof, OR an OIDC ID token, and give an example of dpop
>> proof so that it is clear to the reader that the specification uses
>> three different types of JWTs: DPoP-bound access token, non-DPoP OIDC
>> token, and DPoP proof.
>>
>> If I did not understand some important thing, please let me know.
>>
>> Best regards,
>>
>> divoplade
>>
>>
>>
>>