Hi,
I have a few questions:
According to https://support.okta.com/help/s/article/Why-is-the-GET-Current-Session-API-call-extending-the-users-session:
“This action retrieves the user’s session cookie and extends the session”
- What is the point of /api/v1/sessions/me/lifecycle/refresh if /api/v1/sessions/me also extends the session?
In the following screenshots, you can see two calls to /api/v1/sessions/me/lifecycle/refresh.
In both requests, the sid cookie has the same expiry time of 01:10:46, which means the session is not extended.
This is because the response does not have a sid cookie with an increased expiry date. It only has a JESSIONID cookie.
However, the response body has a new “expiresAt” date time which is what I’d expect.
Does this “expiresAt” time refer to the state stored on the Okta server for my session?
-
How can I get an updated sid cookie with an increased expiry date/time so that my session is extended?
-
What is the point of the SESSIONID cookie?
Why are there the equivalent non-cors endpoints with sessionIds?:
/api/v1/sessions/{sessionId} and /api/v1/sessions/{sessionId}/lifecycle/refresh in Sessions?
To extend the session, don’t you need an updated sid cookie?
If these APIs are meant to be called from our app’s backend, how is the user meant to get a new cookie with an extended expiry?