In the backend I need to validate that the session token received from the client is for an authenticated user of our client web app. Is the /authorize endpoint the way to go?
Okta Help Center (Lightning) which recommends that a session ID can be created. However on Sessions | Okta Developer it says “Don’t use this API unless you need a Session id”
I don’t need a session ID, I just want to validate that session token received is correct. Moreover, a session ID can only be created once per session token, so the operation is not idempotent. Eg the user might click the button several times, and each time I want to validate the session token in the backend, so using session ID will not work. The docs are not clear whether a session can be created from the same session token after a created session ID has been closed using the close-session endpoint.
So I think I should use Retrieve a session cookie through the OpenID Connect authorization endpoint which would lead to an http request like this:
The redirect_uri parameter is weird because I certainly don’t want okta to call back to that URI, but I think this would only happen for other types of /authorize calls than the one documented on that page?
SessionTokens are intended to be exchanged for Session Cookies, they’re not really meant to be validated in the way you are talking about. What’s the purpose of validating a sessionToken that servers as proof that the user was able to complete primary authentication within Okta, without the user actually getting an Okta session?
SessionTokens are ephemeral, so yes, you can only use them once to create a browser session. Once that browser session is created, the end-user will be able to SSO to their applications in Okta.
You would only use the technique you mentioned if the goal is to log the user into an OIDC application. If you just need to start an Okta session, you would use this endpoint instead: Work with Okta session cookies | Okta Developer
Note that SessionTokens are NOT used in IdX and will only be returned if you’re using the Classic /authn endpoint. If you want to use Identity Engine specific functionality, you will want not want to use /authn.
OK thanks, well let me take a step back, maybe explaining the flow will help (I do not control most aspects of this, just that one function that needs to validate the request:
- client: user logs in via okta
- client receives session token
- client shows page
- user navigate to another page and clicks a button
- this hits the backend
- the backend uses the AWS SDK to invoke an AWS lambda that runs some python code
- the python code is rather critical from security perspective so it should verify that the information from the backend corresponds to a user that was authenticated via okta (eg, so that the lambda can only be called through that client and not just directly invoking it from just anywhere in the infra)
- the code can then proceed and do its job
The second to last step is where I’m at.