Assigned... we'll look into it.

Hi Pawel, if you are talking about timeout for ping and push flows, yes, we are sending those requests to the back channel client notification endpoint, you should have CIBA job running in your env and also see this log during timeout processing. Authentication request id {} has expired You should have properties set for CIBA based on docs: https://gluu.org/docs/gluu-server/4.3/admin-guide/ciba/#json-configuration In this context we have these properties:

• backchannelRequestsProcessorJobIntervalSec
• backchannelRequestsProcessorJobChunkSize

Hey, thank you for answering. I am aware of backchannel notification endpoint, but my use case is "I need to execute some action on backend side" in case of such event happening - for which backchannel doesn't really help. Would it be possible to handle it for above case?

Currently there is no backchannel notification in case session expires, some workaround could be using exp claim in order to see expiration date, or also using introspection endpoint to verify whether a given token is still active.

Thank you for answering.

Hey, getting back to the topic. I have explored our possibilities about catching the expired ciba session for emitting the timedout event.

• the job itself throws an exception while called, as in attached log file. It looks like Resteasy is missing some dependency or configuration to make it work as expected,
• the job itself deletes the ciba request after it's expired - that might influence any other scheduled job, leading to missing out events if our job runs after that one.

How would that introspection endpoint behave in case of expired/removed ciba request?

Hi Pawel, sorry for the delay, have you been able to get rest call working? I'm suspecting we are missing some lib, but it's weird to me because we ran all certification and we also have other parts where we are processing rest calls like JWKS urls. Would you mind sharing which Gluu version are you using please, so can test on that one directly. About expired sessions, in such case it works as regular tokens, AS will return ACCESS_DENIED with HTTP 401.

Hello, thanks for the answer. We have handled the event without the mentioned endpoint - although obviously it would be worth to fix it. As for the date when I was testing it, we were using 4.3.1_04 image. Right now we're on 4.4.0-1, but I haven't tested it with the fresh version, due to above.

Ok, I will setup that version in my local environment and test it accordingly. Thanks!

Hi Pawel, I setup a new environment and I was testing this, however I couldn't reproduce it, I was able to get it working with an external service that consumes and produces application/json and everything worked as expected, not sure why in your case it's throwing an error. I also tested different versions, including both versions that you commented, 4.3.1 and 4.4.0, however everything works.