On 30.6.2014 14:32, Bill Burke wrote:
It is the "price to pay". We can shrink the timeout of the
code. Right now it is 60 seconds. Also, Since we're already creating
a session, might as well have a "state" associated with the session.
think it could work this way. After login will be association of
"code" with UserSession created. And once later user wants to exchange
code, it can be verified if code is associated with UserSession and send
token just in case that it is. Then "code" association will be removed
from UserSession, so it's not possible to exchange same code another time.
It seems to me that it's safer and overhead is not so big, as we already
creating UserSession after login, so only additional thing will be just
this "code" association. My vote is to go for it:)
On 6/30/2014 5:12 AM, Marek Posolda wrote:
> There is one small issue though, that now is possible to exchange same
> code for token multiple times. I am not sure if we already discuss this
> and decide that it's "price to pay" to have stateless TokenService.
> However OAuth2 specs is not so happy with this (See 4.1.2 and 10.5) .
> Did we consider saving codes (or exchanged codes) into DB and have some
> periodic task to cleanup them?
> On 20.6.2014 16:43, Bill Burke wrote:
>> Is there anything else that is stateful about the token service?