I’ve been trying for about a week now to validate my access tokens with no luck. Today I happened to find a message buried deep in my Tomcat system logs that complains about an Okta cookie that was returned from the SSO Widget. The message was (All of the state- and site-specific fields have been obfuscated.):
INFO: A cookie header was received [responseType":["id_token","token","code"],"state":"#####","nonce":"#####","scopes":["openid","email","profile"],"urls":{"issuer":"https://dev-#####.oktapreview.com","authorizeUrl":"https://dev-#####.oktapreview.com/oauth2/v1/authorize","userinfoUrl":"https://dev-#####.oktapreview.com/oauth2/v1/userinfo"}}; okta-oauth-nonce=#####; okta-oauth-state=#####] that contained an invalid cookie. That cookie will be ignored.Note: further occurrences of this error will be logged at DEBUG level.
I’m not exactly sure why it’s complaining about the cookie, but the fact that the “responseType” keyword has a closing quote but no opening quote, and also the double close-curly-braces after the urls section both seem a little problematic.
How are you sending the access token back to the server? Is this a custom Cookie you are setting from the client? of so you may need to encode if first (or just use the access token JWT string directly)
This is not a cookie that I am setting. I am using Okta’s “sso signon widget”, and the cookie that I described is (I would guess) being set by the Okta servers, when they redirect back to my site.
I am not reading that cookie, I am not writing that cookie. I am just reporting what my server logs told me about the cookie. If it’s not a problem from Okta’s side, it’s not a problem for me.
The way I pick up access tokens is by using the “parseTokensFromUrl” method of the Okta signon widget.
if (oktaSignIn.token.hasTokensInUrl())
{
oktaSignIn.token.parseTokensFromUrl(
function success(res) {
// whatever
},
function error(err) {
// whatever
});
}