I was considering "iat" to be the timestamp. I was not thinking there would be an additional timestamp.
On Aug 27, 2012, at 2:13 PM, <[email protected]> wrote: > We have exp > > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.1 > and iat > > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.3 > in JWT. Why do we need a timestamp? > > Replay attacks of the same jwt can be mitigated through the jti claim > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.7 > > What do timestamp and nonce add to these? > > Axel > > > > From: Dick Hardt [mailto:[email protected]] > Sent: Monday, August 27, 2012 10:23 PM > To: Brian Eaton > Cc: Nennker, Axel; Jim Schaad; [email protected] > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > > > On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: > > > On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <[email protected]> wrote: > I have an application for JWT that is not OAuth2. > > Should nonce and timestamp logic go in the application level protocol? > > I prefer to NOT have the application level deal with token validity. > > > > Having said that, nonce's are difficult to implement at scale and I have > heard of many sites that don't implement them fully. > > Nonce alone can't be implemented efficiently. You have to have time stamps > as well, otherwise you are stuck storing ever nonce you've ever seen, forever. > > Even nonce + time stamp is challenging in distributed systems. It adds a lot > of complexity. That complexity is sometimes merited, but not always. > > Thanks for confirming my statement. > > I have stopped using nonce and only use time stamps lately and have made the > system relatively stateless so that a second submission of the token is ok. > That may not work for everyone, but I have found that architecture to be > easier to implement and scale.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
