Hi all,
Pretty new to okta, and to be honest find it a little baffling so I was hoping to get a little advice on a problem I can’t seem to resolve on my own.
When using okta-react with my SPA okta application that I’ve setup for the dev environment (dev.domain.com) I’m using the useOktaAuth() hook to get the authState and authService objects.
When running on localhost, with the okta application setup to point callbacks etc at localhost, it all works perfectly.
However in one of the staging environments the authState.accessToken is undefined.
However isAuthenticated is true.
I need accessToken as I’m using it to decide how to treat the user on the front-end based on their claims (ie admin can access admin pages etc). As mentioned, this works perfectly in my OKTA app pointing to localhost callbacks etc.
(( as a side question, should I have separate okta applications setup for each environment? ))
My localhost apps and dev.domain.com apps are all setup exactly the same in OKTA (baffling btw) as far as I can see. I’ve also moved the users across from one app to the other. So I hope (but don’t know for sure) if they all have the same claims.
I also tried using authService to grab the accessToken with getAccessToken() with no success. The token is undefined here, too:
authService.getAccessToken().then((token)=>{
console.log(token);
});
I’ve been using @okta/okta-react version 3.0.0 and also tried with 3.0.2 with no difference.
Any help would be greatly appreciated.
any CORS related issues visible in the console?
Hi,
No cors related issues showing up. Cors config in ok all setup for both environment.
Just undefined token weird right?
Do you see network tab acting normally (authorization and token request/responses)?
Not sure. I’ll have a look
Hi @phi1ipp - i’ve inspected the network tab. I am not entirely sure what I’m looking for but when doing login I do see a successful POST request to https://<my app domain>.okta.com/api/v1/authn in network tab.
Using the copy as> fetch it gives the following (I cannot see this code, it’s generated from chrome dev tools)
fetch("https://<domain>.okta.com/api/v1/authn", {
"headers": {
"accept": "application/json",
"accept-language": "en",
"content-type": "application/json",
"sec-fetch-dest": "empty",
"sec-fetch-mode": "cors",
"sec-fetch-site": "cross-site",
"x-okta-user-agent-extended": "okta-signin-widget-3.9.0"
},
"referrer": "http://dev.caol.io/login",
"referrerPolicy": "no-referrer-when-downgrade",
"body": "{\"password\":\"PASSWORD\",\"username\":\"email@gmail.com\",\"options\":{\"warnBeforePasswordExpired\":true,\"multiOptionalFactorEnroll\":false}}",
"method": "POST",
"mode": "cors",
"credentials": "omit"
});
This is presumably what’s being issued by OKTA react. I am unable to view the response data for some reason. It simply says “Failed to load response data”. However it is marked as 200OK.
Hi @colinriddell, at very least you can compare what you see on localhost vs your site.
authn is only an authentication portion of the conversation, there should also be requests sent to /authorize and /token as a part of OIDC/OAuth specification, after /authn. So I’d try to check, what I described in #1.
I’m not a React developer or I’d try to give more specific advices, sorry.
Don’t apologise @phi1ipp - I really appreciate any help. I’ll compare it against what happens on local. Good idea.
@phi1ipp - looking at what’s happening in the network window when authenticating correctly on localhost has shown more things that might help.
- The first thing to happen is the POST to
https://<okta-domain>.okta.com/api/v1/authn which happens as mentioned before
- Then there’s a GET to
https://<okta-domain>.okta.com/oauth2/default/.well-known/openid-configuration - this didn’t appear on the live environment
- Then a POST to
https://<okta-domain>.okta.com/oauth2/default/v1/token - This also does not appear on the live environment (where I’m having issues)
- Finally a GET to
https://<okta-domain>.okta.com/oauth2/default/v1/keys presumably getting keys. This also doesn’t happen in the broken environment.
So from my point of view for some reason the live environment isn’t getting the well-known, it’s not POSTing the token and it’s not GETing the keys. Presumably it should be doing that?
Any ideas why it’s not doing that?
Are you sure the first /authn call on your live environment finishes successfully? If you can’t get any details in network, check Okta sys log, it should have a record about the user successfully logged in. Sounds silly, I know. Other than that, it doesn’t make any sense. Maybe double-check from an incognito tab, to make sure that cookies/storage are not affecting you.
I’m always testing / checking from an incognito tab. The authn call from live definitely has a 200 OK response. Green and all good. Can’t see the response body though.
The system log says the following:
OAuth2 authorization request
failure : login_required
The details section seems broken in okta just now and the CSS is all messed up when trying to expand that out, so had to copy and paste into atom to get a feeling for what it said. Lots of specific info about the user and the request. Only other thing that stands out is app.oauth2.as.authorize_failure for the key LegacyEventType.
Actually, that’s not coming up every time. Logs mostly say success
OAuth2 authorization implicit ID token request
success
ID Token coming through ok presumably and that makes sense, but no sign in the logs for successfully getting the accessToken.
The OKTA UI and developer console is a bit clunky 
Logs from logging in on the working localhost environment:
Notice the mentioned of token being granted here, but not in the logs from around 14:06 - when logging in on the live environment.
The description for the error you are seeing is - Okta requires a user to be authenticated first, before trying to obtain a token. It would’ve made some sense if you saw a request to /authorize before a successful /authn request.
At this point I’m not sure what to suggest, to be honest…
Oh ok. But I think the error I was seeing was something else perhps?! As the logs show no errors when triggering the problem. Only difference being localhost gets an access_token and live does not.
I appreciate all your help 
Sorry, haven’t seen your other posts… Are you sure that your application configurations are exactly the same for localhost and live?
As far as I can see. I don’t even know if there are other settings I need to change? Is it good practice to have separate apps in okta for each environment?
Two screenshots with the live app on left, and localhost on the right:
Are you using any custom authorization server? If so make sure your second application is included into its policy.
I guess, having separate apps is OK, as long as you don’t forget to duplicate all the changes.
Only one is listed under “Authorization Servers”. It’s the default one and both my applications are pointing to it. It’s the one created as part of my okta account presumably? It’s https://dev-<some number>.okta.com/oauth2/default
I also have a back-end application. The settings in that are duplicated. I don’t really understand how the OKTA integration with that works. I have a vague idea of what’s happening. I suspect that this isn’t even getting that far though because OKTA is supposed to grant the token directly to my SPA application, right?
Then I include that in the Bearer for requests to my back-end. Presumably if the token is nonsense then my back-end won’t be able to auth against the authorities I’ve setup there…
But I’m not even able to get the token out of OKTA in the first place, so not even get as far as my back-end.
