That is exactly the problem we're currently facing at Dailymotion with the writing of our Javascript SDK. How do you handle this issue at Linkedin? Facebook seems to use the expires_at pattern and just don't rely on expiration time in their Javascript SDK but refresh the token 20 minutes (hard coded in the client lib).
What about providing both values in the response? The expires_in + time would be used by the client who directly obtained the token from the authorization server and expires_at would be used to share the session with a tier (i.e.: javascript to backend via cookies). On 15 déc. 2010, at 01:48, Praveen wrote: > We at Linkedin use expires_in for the user-agent flow, just for the > reasons Paul mentioned. > The one issue is when developers pass the token to their backend. > > Praveen > > On Dec 14, 2010, at 3:56 PM, Paul Lindner <lind...@inuus.com> wrote: > >> For User Agent flow you really really really want expires_in >> >> Do you know how many PCs and browsers have their clock set >> incorrectly? >> >> >> On Tue, Dec 14, 2010 at 3:23 PM, Aaron Parecki <aa...@parecki.com> >> wrote: >>> Agreed. I like the idea of expires_at as well. One of the first >>> things a >>> client is going to do after receiving the expires_in is calculate the >>> current time plus the offset. Makes sense to eliminate one source >>> of timing >>> errors. >>> >>> On Dec 14, 2010 2:54 PM, "Paul Walker" <pjwal...@gmail.com> wrote: >>>> It seems to me that expires_in suffers from the same machine time >>>> synchronization issue and additionally throws in an indeterminable >>>> time >>>> amount, while expires_at would only suffer from the former. >>>> >>>> ~pj >>>> >>>> On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: >>>> >>>>> expires_at requires very good time synchronization for all machines >>>>> involved. >>>>> >>>>> expires_in, while not very exact, is more resilient. >>>>> >>>>> Marius >>>>> >>>>> >>>>> >>>>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <jbh...@exacttarget.com >>>>>> >>>>> wrote: >>>>>> I have same question, Thanks Paul for Raising this >>>>>> >>>>>> Regards >>>>>> Jitesh >>>>>> >>>>>> -----Original Message----- >>>>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >>>>>> Behalf >>>>>> Of Paul Walker >>>>>> Sent: Tuesday, December 14, 2010 4:14 PM >>>>>> To: OAuth WG >>>>>> Subject: [OAUTH-WG] expires_at vs expires_in >>>>>> >>>>>> Has there been discussion of using expires_at as an exact epoch >>>>>> time in >>>>>> seconds as opposed to expires_in which is, at best, an >>>>>> approximation "from >>>>>> the time the response was generated by the authorization >>>>>> server?" I >>>>>> apologize if this has been discussed previously. >>>>>> >>>>>> ~pj >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> >> -- >> Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
