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: "https://appliance.domain.name/mga/sps/oauth/oauth20/authorize?client_id=BbJv5&redirect_uri=https://localhost/&response_type=token&scope=openid+email+profile&nonce=055&state=345&response_mode=form_post"
which returns a response similar to this:
<body>
<p>Redirecting....</p>
<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" />
</form>
</body>
and I would like the expires_in hint to be updated to reflect the real "customized" expiration.
------------------------------
Kim Rasmussen
------------------------------
Original Message:
Sent: Thu August 11, 2022 01:59 AM
From: Shane Weeden
Subject: Programmatically altering the lifetime of issued tokens
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: https://www.ibm.com/blogs/security-identity-access/oauth-jwt-access-token/), 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
IBM
Original Message:
Sent: Wed August 10, 2022 05:08 AM
From: Kim Rasmussen
Subject: Programmatically altering the lifetime of issued tokens
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
------------------------------