<div dir="ltr"><div>I didn't look at the IDP logs yet, all I only know the error was thrown in the SP logs, so it may have just been repeating what the IDP said was the issue.  When I changed the maxTimeSinceAuthn on the SP from 120, to 300 we stopped getting all the calls and the errors.  </div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>--<br><br>Thanks,<br><br>Dan <br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jun 8, 2026 at 5:18 PM Scott Cantor <<a href="mailto:scott@restingparrotsoftware.com">scott@restingparrotsoftware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Jun 8, 2026, at 4:27 PM, Dan McLaughlin <<a href="mailto:dmclaughlin@tech-consortium.com" target="_blank">dmclaughlin@tech-consortium.com</a>> wrote:<br>
> <br>
> I found the problem.  We had maxTimeSinceAuthn=120. It's been like that since 2021, and we hadn't seen issues.<br>
<br>
I assumed you meant the IdP was reporting a failure. An SP issue is a different matter, but that setting is about controlling use of old sessions, not limiting the risk of bearer token protocols.<br>
<br>
The assertion is short lived regardless. If you want to control that transit limit, there are semi-obscure ways to do it (it's in the security-policy stuff essentially), but it isn't that setting.<br>
<br>
-- Scott<br>
<br>
</blockquote></div>