[Openid-specs-ab] Session Management: Security Considerations

[John Bradley]

Yes but I think Andreas is talking about XRSF protection for the Refresh token endpoint at the IdP.

At that endpoint the OP needs to check the session status of the user via cookie or other appropriate menthol and only issue a refreshed id_token through valid user session.

In looking at 3.2.1 state is used for client XSRF protection and that is returned in the fragment.  
It would probably be better to use nonce like we do in the main flow to tie a signed claim in the id_token to the session. or we should say that nonce stays the same between refreshes.
That is not in the session spec.

Using state to protect against XSRF in session needs to be expanded.

John


On 2011-09-01, at 3:06 PM, Breno de Medeiros wrote:

> On Thu, Sep 1, 2011 at 10:56, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> I think you are referring to XSRF protection for the Refresh Session
>> endpoint.
> 
> I am talking about XSRF protection for all places in the client where
> they accept id_tokens (or access_tokens for that matter).
> 
>> Check Session is a direct POST from the client to the Check Session
>> endpoint, for a web server client that would not go through the browser.
>> John
>> On 2011-08-31, at 8:51 AM, Andreas Åkre Solberg wrote:
>> 
>> I'm referring to OpenID Connect Session Management 1.0 - draft 03.
>> http://openid.net/specs/openid-connect-session-1_0.html
>> If we consider is a user agent that logs query string parameters in history
>> (In example Safari does).
>> Say that user A logs out of service X, and the service ends the session at
>> the provider as well, this means that the ID Token of the terminated session
>> may be present in the browser history (depending of whether the logout flow
>> includes redirects or displays a info page…).
>> Say that user B logs in to service X right after, waits for the session to
>> time out, or force the check session request by other means, and the user is
>> redirected to the provider check session endpoint. Now user B crafts the
>> response to this request, putting in the ID Token from user A (that is still
>> valid!).
>> Now user B is authenticated as user A.
>> Andreas
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
> 
> 
> 
> -- 
> --Breno

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110901/bf493d06/attachment.p7s>