IBM Security Verify

 View Only
  • 1.  Programmatically altering the lifetime of issued tokens

    Posted Wed August 10, 2022 05:09 AM
    Hi, quick questions about controlling the lifetime of tokens programmatically...

    I have a PreToken mapping rule, where I change the lifetime of an ID token, by calling:

    stsuu.addAttribute(new Attribute("exp", "urn:ibm:jwt:claim", tokenLifetimeSeconds));
    This is obviously recognized as an expiration, since the input is a number of seconds, and the output is the correct unix epoch (current time + the number of seconds) - that works fine for the JWT token.
    But, we are also issuing an access token - the access token is customized, issued by the STS and added also in the pretoken like this:
    stsuu.addContextAttribute(new Attribute("urn:ibm:ITFIM:oauth20:custom:token:access_token","urn:ibm:ITFIM:oauth20:custom:token",jwtToken));
    But here we would also like to change the expiration for specific clients - is there a way to do this programmatically for the access token ?

    Kim Rasmussen

  • 2.  RE: Programmatically altering the lifetime of issued tokens

    Posted Thu August 11, 2022 02:00 AM

    The primary reason for issuing a JWT access token, is to make it self-encapsulated, not pass-by-reference. When doing that you would typically indicate that ISVA should *not* store it at all in the HVDB (see the code for jwt_at_pre.js referenced in this article:, which means that ISVA has no concept of that token's expiry and its lifetime is a function of the iat, nbf, and exp claims within the JWT itself.

    If you are issuing a JWT access token, AND having ISVA store it (undesirable), then ISVA should be using the configured access token expiry for all clients, but you always have the option to override the validation response in the post-token mapping rule. You should cover both the custom call between WRP and the STS during WRP access token validation (request_type="resource") and token introspection (request_type="introspect").  Trace the final STSUU in the post-token mapping rule for these use cases to see what the expiry looks like.

    Shane Weeden

  • 3.  RE: Programmatically altering the lifetime of issued tokens

    Posted Thu August 11, 2022 02:15 AM
    Hi Shane, thanks for responding.

    Fair point about not storing a JWT token, I'll check this out and see if we can avoid it.
    I'll check the STSUU out in the PostToken mapping rule - thanks for the pointer.

    Essentially we have a request like this:
    curl --negotiate --location -c cookiejar.txt -u: ""

    which returns a response similar to this:
          <form id="redirect_form" name="redirect_form" action="https://localhost/" method="POST">
              <input type="hidden" name="access_token" value="eyJraWQiOiJ...snipped...gR5MT-fw" />
              <input type="hidden" name="scope" value="openid profile email" />
              <input type="hidden" name="state" value="345" />
              <input type="hidden" name="token_type" value="bearer" />
              <input type="hidden" name="expires_in" value="899" />

    and I would like the expires_in hint to be updated to reflect the real "customized" expiration.

    Kim Rasmussen

  • 4.  RE: Programmatically altering the lifetime of issued tokens

    Posted Thu August 11, 2022 02:26 AM
    You should be able to update the expires_in as returned to the client in the post-token mapping rule with something like:

    stsuu.addContextAttribute(new"expires_in" ,"urn:ibm:names:ITFIM:oauth:response:attribute", new_lifetime));

    Shane Weeden

  • 5.  RE: Programmatically altering the lifetime of issued tokens

    IBM Champion
    Posted Thu August 11, 2022 09:26 AM
    Try either of these in your post mapping rules:

    OAuthMappingExtUtils.updateToken(token, 1800, null, null);

    stsuu.addContextAttribute(new"expires_in" ,"urn:ibm:names:ITFIM:oauth:response:attribute", 1800));

    I can't recall why I use one over the other, but I have two types of tokens we increase the lifetime on in the post mapping rules.

    As far as the JWT itself, yes what you are doing with the exp claim is what we do for it.

    We do store the JWT in the HVDB.  Of course this requires hashing of the tokens enabled.  This allows the JWT tokens to be revoked and then checked for revocation via the introspection endpoint.  This is a far stretch, obviously most apps won't introspect a JWT, but it does provide that capability if someone wants to use it.  So basically we treat the JWTs no different than opaque tokens, because we allow both based on a parameter that is passed when the token is requested (we default to JWT, but if that parameter is there we generate a simple opaque token).

    Matt Jenkins