Layer7 API Management

 View Only
  • 1.  How to determine cookie expiration?

    Posted Jul 28, 2020 04:40 PM
    Edited by Arun Addepalli Jul 28, 2020 04:41 PM
    Hello,

    From CA API Gateway 9.3, we set a cookie by wrapping id_token provided by OIDC provider and set expiration on the cookie to match the token expiration. From the Gateway policy, we want to check if the cookie passed by Browser with a request is expired or not. How can we achieve that? We do not want to decode the token as Gateway does not own the token. Appreciate any pointers.

    Thanks!
    -arun​


  • 2.  RE: How to determine cookie expiration?

    Broadcom Employee
    Posted Jul 28, 2020 05:13 PM

    Cookie expiration is not transmitted as part of the Cookie header, so this is not possible. That information is set during the Set-Cookie response header and is maintained by the browser. If a cookie is expired the browser is supposed to delete the cookie and not send it.

    Ref RFC 6265 Section 5.3; "The user agent MUST evict all expired cookies from the cookie store if, at any time, an expired cookie exists in the cookie store."



    ------------------------------
    Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
    ------------------------------



  • 3.  RE: How to determine cookie expiration?

    Posted Jul 29, 2020 12:22 PM
    Edited by Arun Addepalli Jul 29, 2020 12:27 PM
    Thanks for quick response.

    Somehow, the FF we are using in a controlled env, is sending the expired token :-(

    So, the only way for CA API Gateway to determine if a cookie/token is expired is by decoding it and comparing the expiration time to current time? Any other way available? Decoding token for every HTTP request is expensive!

    PS. As a proactive way, from CA API Gateway, we want to know if a token is "about" to expire and do a 302 to OIDC provider to get a new token.

    Thanks!
    -arun


  • 4.  RE: How to determine cookie expiration?
    Best Answer

    Broadcom Employee
    Posted Jul 29, 2020 02:55 PM
      |   view attached

    Since the information is not part of the Cookie header, then yes, you must determine the expiration details by decoding the token. I would recommend using the internal cache to maintain the expiration time and avoid continually going to the token authority, though. The token is first presented to the policy and validated, cache the expiration time keyed to the token string itself. That way whenever it shows up again you have that bit of information. In a cluster the other nodes will do the same on first encounter.

    Import the attached policy into a test Web API service on a gateway and access it using a browser to see what I mean. When first accessed it will check if the access_token's expiration is in the cache. If not found it will set ${token_eol} to a time 10 seconds in the future, convert that to a string and cache it with a 15 second cache life. On subsequent accesses (keep refreshing your browser) it will retrieve the value from the cache, convert the string to a Date/Time variable and compare first to the current time to see if it is expired, then compare it to a timestamp 3 seconds in the future to see if it is about to expire, otherwise it indicates that the token is not expired.

    First access (retrieved token from token authority [i.e. set to 10 seconds in the future] and cached expiration value for 15 seconds):

    access_token=randomstring
    gateway.time=2020-07-29T18:38:12.426Z
    token_eol=2020-07-29T18:38:22.424Z
    note.source=Set and stored in cache
    note.state=Token is not expired

    Second access (found in cache and expiration is greater than three seconds in the future):

    access_token=randomstring
    gateway.time=2020-07-29T18:38:14.214Z
    token_eol=2020-07-29T18:38:22.424Z
    note.source=found in cache
    note.state=Token is not expired

    Third access (found in cache and expiration is less than three seconds in the future):

    access_token=randomstring
    gateway.time=2020-07-29T18:39:20.018Z
    token_eol=2020-07-29T18:38:22.424Z
    note.source=found in cache
    note.state=Token is about to expire

    Fourth access (found in cache but expired):

    access_token=randomstring
    gateway.time=2020-07-29T18:38:23.016Z
    token_eol=2020-07-29T18:38:22.424Z
    note.source=found in cache
    note.state=Token is expired

    Fifth access (token not found in cache - expired from cache or this is a new node in the cluster):

    access_token=randomstring
    gateway.time=2020-07-29T18:38:28.136Z
    token_eol=2020-07-29T18:38:38.134Z
    note.source=Set and stored in cache
    note.state=Token is not expired

    You should be able to use this policy as a template for your own validation, etc.





    ------------------------------
    Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
    ------------------------------

    Attachment(s)

    xml
    TokenExpirationDemo.xml   12 KB 1 version