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

> What is its use then?

There are two parts to this:

1. In order to conform to OIDC, producing an ID token is a required feature
2. A client may wish to display information about a user (e.g. a profile
image, a name, etc) as asserted by the identity provider.

A client isn't required to use the data in the ID token, but the webid
claim would likely be useful.

> Should I infer that it may be used to refresh the dpop-bound access token?

Here, you are thinking of a "refresh token". That is a third type of token,
which (if an identity provider supports that feature) can be retrieved from
the token endpoint if the "offline" scope was part of the initial
authorization code flow request.

-Aaron

On Tue, 6 Oct 2020 at 08:52, divoplade <d@divoplade.fr> wrote:

> Hello,
>
> Le mardi 06 octobre 2020 à 08:31 -0400, Aaron Coburn a écrit :
> >
> > 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.
>
> This is what I was missing. It is only used between the client and the
> identity provider. What is its use then? It is not used to get a dpop-
> bound access token, since it is issued at the same time. The
> informative basic flow section does not use it either. Should I infer
> that it may be used to refresh the dpop-bound access token?
>
> divoplade
>
>