Hi

I believe that when WebSEAL (with oauth-auth=https configured) receives inbound an OAuth token inside a Bearer header, it performs a validity check with its configured STS services (using WS-Trust), but only once. All other following inbound calls with the same Bearer token will be considered already validated, up to its expiration time.  Is this right?

Now, without going to the extreme other scenario where we would tell WebSEAL to validate every incoming Bearer token with the STS regardless it may have validated it already, is there a way to tell WebSEAL to revalidate a pre-validated Bearer token every now and then? This is to make sure that if the token as been invalidated administratively (from the LMI) or by other means (revoke end-point), that the Deny authorization process can take effect somewhat more rapidly.

I guess this is more applicable to scenario with long token (1h or more), compare to cases where the tokens are set to relatively short duration (5 min).

Also, what is it with this thing about calling the same thing with 2 different names: "Bearer" or "OAuth" token. I'm sure some on this group can provide a pre-historic perspective on the matter. (-; I know it may sound "cooler" to say "Bearer" token ... can it be really something else than an OAuth token? That was my Friday trivia question.

Sylvain

Got it.

So it has more to do with the fact that WebSEAL looks for Bearer token in Authorization header only when it is not finding session information (cookie). When it does find a still-valid session in subsequent requests, it just does not care or bother that an Authorization header is still present.

Thanks