[Openid-specs-ab] Session

[Breno de Medeiros]

On Wed, Apr 13, 2011 at 11:42, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
> 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?

No, only one, the renew_id_endpoint.

There's an additional 'helper' endpoint that just validates the
id_token (doesn't give you a new one). This endpoint is only needed
for parties that can't do crypto-based JWT verification, and they only
use that in subsequent validations of the token (when they first
obtain a token via backchannel call they know it's valid because it's
coming from the proper endpoint).

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



-- 
--Breno