I’ve spent hours on this today. Perhaps I’m just missing something basic.
If I leave out the client id, and all the stuff I NEED to be able to set, it does indeed work and redirect… but I don’t see the token in the HTTP headers… why?
If I DO set the client id, then I can’t redirect at all (session is undefined) and the token is returned in res (I don’t want that).
I don’t want JS to have access to the token, I want it to be set as a secure http only cookie and then to retrieve it in the headers at my redirect URL.
Isn’t okta supposed to be able to do this?
HOW in the heck do I get this thing to just redirect to my URL and have the token appear in as an http only cookie??
If you’re using the Okta Sign-In Widget, there’s no way to store your token as an HttpOnly cookie. The widget can only get tokens for you via the implicit flow, where the tokens are returned in the # fragment of the callback.
What type of application are you working on? If it’s a JS single-page app, this is the recommended way to do it. If you have a server backing your app (Express, Django, ASP.NET, etc) then you can set an HttpOnly cookie in your backend server code.
If you post more details about what you are working on, I can provide more suggestions.
Somehow, I have this thing stuck on the OIDC flow. What am I doing above that is causing that? I will say, this thing is infinitely harder to use than you advertise. I would have had this done hours ago using aws cognito.
You need to set display:'page' to force the widget to go through the OIDC flow (redirecting to your redirect URI, with the id_token in the fragment).
I know this configuration isn’t clear. We are going to be revisiting widget configuration shortly to make sure the configuration and parameters are clear.