[Openid-specs-ab] Session

[John Bradley]

On 2011-04-13, at 2:20 PM, Breno de Medeiros wrote:

> 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.

So are there two separate endpoint where a ID_token can be renewed?

I thought that it was only going to be one endpoint hence no UI.

I agree that is like immediate mode at the authorization endpoint but lighter weight.

> 
>> 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.

Good,  so two tokens returned for the web server flow,
The User agent flow gets the access token through the browser and then uses it to retrieve the ID_token.

John B.

> 
>> John B.
> 
> 
> 
> -- 
> --Breno