<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D54z000075wtXNCAYOkta Classic EngineAuthenticationAnswered2026-05-27T22:59:21.000Z2021-08-02T22:58:23.000Z2026-05-27T22:59:21.000Z
The NotOnOrAfter, NotBefore and IssueInstant indicators on SAML response message are stamped with a future timestamp.

I am trying to consume a SAML assertion sent by OKTA. The XML has the following Conditions node

 

<saml2:Conditions xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"

             NotBefore="2021-08-02T22:49:52.995Z"

             NotOnOrAfter="2021-08-02T22:59:52.995Z"

             >

 

and the following IssueInstant on the response node

IssueInstant="2021-08-02T22:54:52.995Z"

 

This was generated at 18:54:52 according to my server time.

How can the discrepancy between IdP time and SP server time be tackled? I am trying to enforce an expiration for the SAML assertion but this puts the assertion 4 hours in the future which is an unnecessarily long time for the assertion to live. Also, I cannot enforce NotBefore with this setup.

 

These were generated at


  • I realized after posting this issue that this was a non issue to begin with. OKTA is already sending a timestamp with a TimeZone identifier (the Z at the end of the timestamp indicates UTC). On our end the C# method DateTime.Parse("2021-08-02T22:54:52.995Z") correctly identifies this as a UTC timestamp. When I do a date comparison similar to the below code, C# automatically provides local time for comparison which is in the correct time range.

    ```

    var notOnOrAfter = DateTime.Parse("2021-08-02T22:49:52.995Z");

    bool isValid = DateTime.Now < notOnOrAfter;

    ```

    There is no action needed here. Thanks for your response.

    Expand Post
    Selected as Best
  • User16113532018866032757 (Vendor Management)

    Hi!

     

    In regards of this matter, I understand you and the issue you're encountering.

    To be able to get to a resolution on this, I think the shortest path to a resolution would be to create a ticket on this so we can get into a screen sharing session so we double-check the flow and the use case correctly and after that do the right changes.

    Please make sure to get in touch with us through a new ticket and we'll be more than happy to assist you. Looking forward for that!

     

    All the best!

    Expand Post
  • I realized after posting this issue that this was a non issue to begin with. OKTA is already sending a timestamp with a TimeZone identifier (the Z at the end of the timestamp indicates UTC). On our end the C# method DateTime.Parse("2021-08-02T22:54:52.995Z") correctly identifies this as a UTC timestamp. When I do a date comparison similar to the below code, C# automatically provides local time for comparison which is in the correct time range.

    ```

    var notOnOrAfter = DateTime.Parse("2021-08-02T22:49:52.995Z");

    bool isValid = DateTime.Now < notOnOrAfter;

    ```

    There is no action needed here. Thanks for your response.

    Expand Post
    Selected as Best
  • I cannot edit my previous response, however if someone else lands here, reference the following timestamp serialization notation

     

    • 2009-06-15T13:45:30 (DateTimeKind.Local) --> 2009-06-15T13:45:30.0000000-07:00
    • 2009-06-15T13:45:30 (DateTimeKind.Utc) --> 2009-06-15T13:45:30.0000000Z
    • 2009-06-15T13:45:30 (DateTimeKind.Unspecified) --> 2009-06-15T13:45:30.0000000

     

    the last part of the timestamp is the Time Zone Designator per ISO 8601 standards and is reserved to indicate UTC time correction. If a timestamp is properly serialized the DateTime library that you use to parse it (System.DateTime in C#) should be able to correctly parse the OKTA timestamp as a UTC timestamp and when comparing timestamps should provide local time when the object is used for comparison. If you are using some other programming language or framework that does not handle this properly consider implementing a DateTime parser that can do this for you.

     

    References:

    https://www.w3.org/TR/NOTE-datetime

    https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings#table-of-format-specifiers - round-trip date/time pattern

    Expand Post
This question is closed.
Loading
The NotOnOrAfter, NotBefore and IssueInstant indicators on SAML response message are stamped with a future timestamp.