[Openid-specs-mobile-profile] How to invalidate cookie sessions in RP

Mon Mar 28 22:17:46 UTC 2016

Yes it is a public spec.

The problem is that they don’t maintain the info on the server so that they can kill the cookie based on a out of band signal. 

They try to be stateless and keep everything in cookies.    Given that the out of band signal is not coming through the browser they can’t just get the signal and wait for the session to turn up again at the server to kill the cookies.

It is not that hard but it is not something that most RP can do. 

The problem you will have is that you are not going to want to keep session information around forever.  

After the session at the IdP has expired and the dependent Id_tokens have expired, you are going to clean up any session info.

If the RP sessions last longer than the id_token then the IdP won’t know who to send messages to.   At that point you would need to send a de-provision  type message to every SP the user has ever logged into.  That has privacy issues, and is similar to what the RISC working group at the OIDF is looking at with account takeover messages.

John B.

> On Mar 28, 2016, at 5:32 PM, GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com> wrote:
> 
> Hi John,
> 
> First of all thank you for your quick response. 
> 
> I agree that having persistent session cookies is not a good practice. However there are some Service Providers that can’t decide how many time set for expiration cookies and they suggest somehow to be warned in case the user is unsubscribed. We would have a similar problem if the cookie expires after the id_token, however this case can be managed setting the id_token in the cookie.
> 
> You said that “Most SP don’t retain enough of the session in the server to be able to correlate and kill a front channel session based on a out of band signal”, are you talking about legacy code that sets “something” in the session cookie? If I understand well this could also be avoided setting the id_token in the cookie right?
> 
> BTW, is public the spec you are working on for the back channel?
> 
> Best Regards and thank you again,
> Gonza.
> 
> De: John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
> Fecha: lunes, 28 de marzo de 2016, 20:33
> Para: Gonzalo Fernandez Rodriguez <gonzalo.fernandezrodriguez at telefonica.com <mailto:gonzalo.fernandezrodriguez at telefonica.com>>
> CC: "openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>>
> Asunto: Re: [Openid-specs-mobile-profile] How to invalidate cookie sessions in RP
> 
> There specs for logout in the front channel using redirects, and one I am working on for the back channel.
> 
> It is probably a bad practice to have session cookies that don’t expire.  We have seen requests for logout, but not a account deprovisioning other than through SCIM or something like that.
> 
> I would ask why a user being unsubscribed to mobile connect is a problem for the SP as long as the session is good.   Is this different from logout?
> I can potentially see backchannel logout being required if the user doesn’t have an active browser session.
> 
> I think what you will find on the web is that most SP don’t retain enough of the session in the server to be able to correlate and kill a front channel session based on a out of band signal.
> 
> So while SP do ask for back channel logout, most of them decide that they can’t do it based on how the site is designed around cookies.
> 
> I think the closest thing is backchannel logout, but most RP/SP won’t do it.
> 
> It is exactly the same problem in SAML and almost no one uses the SAML SLO spec for that reason.
> 
> John B.
> 
>> On Mar 28, 2016, at 2:37 PM, GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com <mailto:gonzalo.fernandezrodriguez at telefonica.com>> wrote:
>> 
>> Hi guys,
>> 
>> I would like to know your opinion as experts in OIDC about how to invalidate the session cookies in the RP in case of a user abandons Mobile Connect. I mean, I am thinking in the next problem:
>> 
>> A Relaying Party “RP1” using Mobile Connect authenticates the user “user1” using Mobile Connect in an MNO.
>> The relaying party sets a cookie, likely with the id_token (to be able to check the expiration) for a long time.
>> The user “user1” is unsuscribed in Mobile Connect, however he can still be authenticated in the RP1 relaying party because the cookie is still valid.
>> The question is if there is some standard way to proceed to communicate the RP1 that the user “user1” is no longer is Mobile Connect subscriber, and allow the RP to invalidate the cookie.
>> 
>> Best,
>> Gonza.
>> 
>> 
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>> 
>> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
>> 
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
>> _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net <mailto:Openid-specs-mobile-profile at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile <http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile>
> 
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160328/b4821dc1/attachment-0001.html>