We are trying an upgrade from 6.5.3 to 7.2.1 and experiencing an issue with the OAuth Auth Code exchange against the realms/[realmname]/access_token endpoint where it now returns “Invalid session ID.Session not found. This likely means it has expired and been removed.”
Looking in trace logs we get the following exception:
Caused by: org.forgerock.openam.dpro.session.InvalidSessionIdException: Invalid session ID.Session not found. This likely means it has expired and been removed.
We’ve looked and the Auth Code is still live in CTS; and after attaching a Remote JVM debugger to AM we’ve spotted it appears to be an issue finding the SSO Session thats associated with the auth code. This is within org.forgerock.oauth2.core.AuthorizationCodeGrantTypeHandler where the sessionID is taken from the Auth Code and it is looked up.
Any ideas of settings to explore? We’ve not modified settings we configured as part of the upgrade to 7.2.1 from 6.5.3
Have you gotten Message level logs and searched on that transaction id further?
You can also search the transaction id in DS and it will be shared.
Looking at 7.2.1 there was:
- OPENAM-16241: Switching CTS Storage Scheme with stateful refresh-tokens from 1-1 to grantset
And 7.2.0 has
- OPENAM-17973: Retrieving auth code in a realm fails if session for another realm exists
You can look some at the release notes to see if any other fixes/changes affect the areas your investigating.
Fixes in 7.2.x :: ForgeRock Access Management
Can you check if your hitting the wrong realm or some more details around your rest call parameters to understand a little more what your sending?
Looking at the whole transactionid may help see more why this fails, than just the exception piece.
I’m sorry to hear you’re experiencing issues during your upgrade from AM 6.5.3 to 7.2.1. I wanted to reach out to you and confirm that our development/sustaining engineers are working on the issue with the “invalid session ID. Session not found” error message through a support ticket and making progress as expected. Please let me know otherwise.
Additionally, it would be greatly appreciated if you could share the solution with the community once it becomes available, as it could potentially benefit other members facing similar issues.
@salbertelli01 - Yes thank you the support ticket has now reached engineering and more than happy to progress investigations through that route. Raised the community ticket in case we’d missed something obvious during upgrade. Happily will share the result/solution here when we get to the bottom of it.
@william.hepler - Thank you for replying to the post too. Our support engineer got us to toggle the CTS Storage Scheme between 1to1 and grant set with no change in behavior seen. We are hitting the right realm double checking the Postman collection we test this with. We’ve also upgraded to 7.3 to see if issue exists there and still experiencing it following on 7.3 too.
Will see where the engineering investigation goes and update here soon after.
Thank you so much for sharing the progress update on the investigation. It’s really appreciated. I’m glad to hear that your support ticket has made it to engineering, and I’m hopeful that they’ll be able to provide a solution soon.
You’ve been incredibly thorough in your troubleshooting, and it sounds like you’ve done everything you can to resolve this issue. I appreciate you sharing your experience and the steps you’ve taken.
Your insights are invaluable and could help others with similar issues. Thanks for your help, and please reach out if you need anything else.
This was found to be a bug introduced in AM 7.1 thought to be linked when Backchannel Logout was introduced.
If you also experience the above problem (if you can) follow OPENAM-21004 to track the bug fix progress.