I have a Java web app with my own customized logon page. After obtaining the sessionToken by calling the /authn endpoint, I then call /authorize in the following format:
https://my.oktapreview.com/api/v1/oauth2/authorize?client_id=0123456789abcdefg&response_type=id_token&scope=openid&prompt=none&redirect_uri=https%3A%2F%2Fmy.domain.com/myApp/myLandingPage&state=Af0ifjslDkj&nonce=n-0S6_WzA2Mj&sessionToken=20111xECQD6Z1Gc0SeTI9lCZZyib-od6pT5LHgrmIgUCCVwtmfUd8P_
Everything seems fine and I get redirected to my landing page successfully.
However, if I understand the documentation correctly, this should also set a session cookie (I think the cookie name is sid) for the domain “my.oktapreview.com” so that I won’t need to be authenticated again if I try to log on to my.oktapreview.com. Instead, I still get the Okta logon page when trying to access my.oktapreview.com, and on examining the cookies for my.oktapreview.com, I don’t see the “sid” cookie either.
Is this a bug or am I missing something?
What does the response from that request look like?
The Chrome network trace didn’t show much. Just one entry. A response code of 200 for testSSO.jsp (which is the page I call to execute all my /authn and /authorize logic) and the browser was redirected to my landing page.
Do you have the preserve log turned on?
Are you seeing the call to my.oktapreview.com/.../authorize ?
Yes, I have preserve log turned on. Since the /authn and /authorize calls are made in the server, I think that’s why the Chrome trace only showed a response code for testSSO.jsp.
But on further testing, I found the following:
If I remove the prompt=none parameter from the /authorize call, I’ll get redirected to the Okta login page and session cookie “sid” for my.oktapreview.com is set after login and subsequently redirected to my landing page.
On the other hand, if I include the prompt=none parameter and the session token obtained from /authn as I described earlier, I get redirected to my landing page without the intervening Okta login page, as expected. However, the session cookie “sid” is not set for my.oktapreview.com. This seems to be in contradiction to the Okta doc ( https://developer.okta.com/use_cases/authentication/session_cookie#retrieving-a-session-cookie-via-openid-connect-authorization-endpoint ):
“Once a session token is obtained, it can be passed into the OpenID Connect authorize endpoint in order to get an Okta session cookie. Executing this flow will set a cookie in the end user’s browser and then redirect them back to the redirect_uri that is passed into the request.”
Any idea why?
Hey @wleungucla!
You will need to route your /authorize call through the browser to get it to set a cookie. If you send it through from your server, the user’s browser wouldn’t come into play until your server handles the response.
Does that help?
My testSSO.jsp, which contains the /authorize call, is launched from the browser as follows:
https://myServer/myApp/testSSO.jsp
Was that what you meant by routing the /authorize call through the browser?
Sorry @wleungucla, I might be missing some context. You had mentioned the /authn and /authorize calls were done on the server side. For the sake of the discussion let’s try to take the JSP concept out (since it can both run code on the server and render code for the client/browser).
I’m guessing you have a page that collections a user’s credentials and sends them to your backend service. This service makes the call to the /authn API directly and you end up with a sessionToken. From that point are you making the /authorize call from your server?
Yes, that’s exactly what I have.
But I want to clarify in case you think it makes a difference. For the purpose of POC, I have skipped the user credentials collection part and basically hardcode user name and password to call /authn. So It’s not a form submit to invoke the backend.
Hello @wleungucla, Did you find any solutions? I am also facing the same issue . Any help would be appreciated !