[Openid-specs-ab] Session

[Breno de Medeiros]

On Wed, Apr 13, 2011 at 11:12, John Bradley <ve7jtb at ve7jtb.com> wrote:
> To summarize, so that I have it strait.
> So in the main flow you get a access token.
> You use the access token to get the signed ID token from the get_id_token
> endpoint.
> For 3 rd parties where they may not have access to the symmetric secret, or
> particularly lazy clients who don't want to support base64 decoding etc
> there is a check_id_token endpoint (direct) that returns a unsigned JWT.
> There is a renew_id_token endpoint via redirect.
> You say
>
> There’s no UI at this endpoint -- however, immediate mode can be used to
> suppress login page, which otherwise will be shown when user is not
> signed-in.
>
> Perhaps the immediate mode reference is old?  From when we were talking
> about re-using the authorization endpoint.

No. I didn't fully document this, but we plan to honor expired JWT
tokens for exchange at the renew_id_token endpoint *as long as the
user is signed in and the grant has not been revoked*. The reason for
this is to maximize opportunity for usage of the lighterweight
renew_id_endpoint versus the heavier two-step process of getting an
oauth token and backchannel swap for id_token in the common case.
OAuth tokens requests are likely to be not as frequent as
renew_id_token requests.

I agree that I need to expand this more.

> In the JWT token we should also include a nonce to prevent replay types of
> attacks.
> Towards the end you indicate that the id_token may come directly from the
> token endpoint along with the access token.
> Which id_tokens are usable for session synchronization purposes and which
> are not? To keep things simple for clients, if the client obtains an
> id_token either by:
>
> - Redeeming a code, always obtained via indirect communication through the
> browser;
> - Supplying an access_token to the get_id_token endpoint where the
> access_token was obtained via indirect communication through the browser;
> I am not against returning the ID_token from athe token endpoint directly,
> but I thought that you wanted it to be a separate call.

The reason it's a separate call in the UserAgent flow is to return it
in the backchannel so that it's tied to the oauth_token. In the
webserver flow it is quite inefficient and unnecessary to make this
another backend call.

> John B.



-- 
--Breno