reuse valid token

Registered by yong sheng gong on 2013-08-23

This blueprint has been superseded. See the newer blueprint "Non-persistent PKI tokens" for updated plans.

Now if we call the auth API with the same authentication information, the keystone will always return a new token. This behavior sometimes will bloat the token table with valid tokens when the auth API is called too often and the expiration time is long.

This BP tries to reuse the same token when the existing token has the same scope as the expected new one. We try to reuse the existing token if the expiry time is within a scope ( threshold). We will not change the reused token's expiry time, i.e. we return the old token as it is.

the IRC discussion logs:
https://docs.google.com/document/d/1RUARZCQzbS4QnXV3Mod3ZLg9oj-oHR_kR0S6APiVk1A/edit?usp=sharing

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
yong sheng gong
Definition:
Superseded
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Morgan Fainberg on 2014-01-23

Whiteboard

what if my token is about to expire and i want a fresh one?

yong sheng gong said: I think we can allow 'admin' role to have this privilege to have a fresh new one token with specific API parameter. The system reuses the token according to the threshold value for normal user API access.

Sean McCully <email address hidden>:
Hi Yong Sheng,

Just wanted to follow up on this Launchpad bug, not sure if you've already knocked it out. But this is roughly a rough draft of how I think it would be implemented. No pressure to use any of my code or anything, just thought I would put it out there.

https://github.com/seanmccully/keystone/tree/recycle-tokens

yong sheng gong said: https://github.com/openstack/python-keystoneclient/commit/d734821c99aade7cd4285a5fd51736c475707dcd
it seems the client has done with it via keyring.

(morganfainberg): I'll post this here as well, it's copy-paste from the bug #1215627:
This seems like the wrong approach. If a token is meant to be re-used the client (be it the python-*client OS provides or something else) should use it. New authentication should result in a new token (regardless of storage of said token on the backend). Re-issuance of the same token is a bad idea and breaks with the general direction we are trying to go with having truly ephemeral tokens.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.