I also consider token expiration not an issue we should deal with currently.
Also, the timeout of 24hrs may even be raised to e.g. 48hrs. More 
important, it seems, is to incorporate the Logout function into the 
workflow, to invalidate the token after the task has actually finished.
User tokens may be indeed employed in service-to-service connections, 
when permissions are necessary that the requesting service does not have 
(e.g. retrieving a specific dataset). As mentioned earlier, services 
should generally have user accounts too, akin to any service/daemon on a 
stand-alone computer.

Greetings
Andreas


Luchesar V. ILIEV wrote on 06/17/2010 12:55 PM:
> I second Nina's opinion on OpenSSO hardly providing any mechanism to
> implement such token "half-life". On the other hand, we have the
> following general workflow:
>
> 1. User acquires token via client application.
> 2. Client application uses token with various services.
> 3. The services use token on behalf of user when necessary.
> 4. On getting the final results, the client "logouts" the token.
>
> Thus, for each user-initiated "computational flow" through the OpenTox
> services, a "freshly-issued" token will be used. Considering that
> currently the tokens have 24 hours validity, I find it rather unlikely
> to have many cases of tokens expiring "in transit". That's why I'd
> rather consider the token expiration a non-issue, at least for the
> time being.
>
> Of course, it would be somewhat different with people communicating
> directly through the API with the OT services. Obviously, they will
> handle the authentication themselves, and thus it's upon them to keep
> an eye on token validity. Still, if they are proficient enough to use
> directly the API, that shouldn't be a problem.
>
> Further, we could prepare some "best practices" document, which could
> give suggestions on how to specifically avoid these issues, e.g.
> always use "fresh tokens", or "don't use tokens that have less than N
> hours validity, etc. Actually, the "best practices" might be handy for
> many other things as well: e.g. what is considered "polite" use of the
> OT infrastructure, that is what needs to be avoided in order not to
> overload it...
>
> Cheers,
> Luchesar