401 Unauthorized Error response

I was getting 401 unauthorized error while implementing the post call for the “oauth2/v1/token” end point in the react next js app but in the postman it was giving 200 response fine. Please help me someone

Do you see a specific error message when you get that 401? How are you authorizing the request in Postman?

1 Like

Hi @andrea, I dont see any particular message other than status code: 401 Unauthorized on the network tab. In the postman I was using basic authorization and in the headers I was passing (Accept-application/json, Authorization- basic) and in the body I was passing (grant_type: authorization_code, redirect_uri: *****, code_verifier: ****, code: ****, state: ****) and getting the access_token

How are you filling out that Authorization header? Is it (base64 encoded) Client ID:Client Secret?

I suspect you may have created a Web application within Okta, which supports Client ID/Client Secret auth, whereas (presuming you’re using our SDK) the React app is designed to work with a SPA using [PKCE] auth (Implement authorization by grant type | Okta Developer).

If you create a SPA and use its Client ID instead, does your React/NextJs app work?

1 Like

I was using PKCE (Implement authorization by grant type | Okta Developer ). approach only. I was getting code & state from /authorize end point and after that I was making post call to the /token end point to get the access token. So in my code in Headers I was passing (Content-type , Authorization: Basic(clientid+clientsecret), Accept: application/json) and in the body (code, code-verifier, redirect-uri, grant type) not sure why still seeing 401

What type of application did you create within Okta? If you navigate to the General settings, do you see a Client Secret, or do you see “Client authentication” set to none with PKCE enabled?

I can see client authentication as client secret and PKCE is enabled.

If your app has a Client Secret, you will not be able to use AuthJS (and by extension, Okta’s React SDK) to handle the /token request.

Do you plan to have a backend for your integration that you will use to manage the application session and secure the users tokens? If not, you likely want to try creating a Single Page Application (like in my screenshot) which will work directly with Okta React so that you can receive tokens on the front end.

ok this is tricky actually then. Because our app is a single app which has both backend and frontend and for the backend we are actually using nextjs. I really can’t create a separate app to call the token end point. it has to be in same app itself because that’s how it was designed.

In that case, would you be able to configure it so your backend can handle the callback to exchange the auth code for tokens?

I don’t know Andrea, I was kinda lost now whatever I was doing it was kinda baackend implementation only. Authjs is just a framework right.

AuthJS is focused around primary authentication (into Okta) and authorization (into an OIDC app) and is relatively barebones otherwise. The framework SDKs (Angular, React ,Vue) that are built on top of it have a bit more going on as they help you set up the callback route and secure all the other routes so that user authentication is required.

When the React app makes the /token call, do you see an Authorization header included, or do you only see the Client ID included in the request body? If you don’t see the header, have you configured the clientSecret in the OktaAuth config?

So in my react app in the headers I was passing Authorization as basic and in that basic I was encrypting bas64 which has (clientId + clientSecret) and also I configured client Id and client secret in my OktaAuth config as well

or else is there something wrong with the OKTA config and set up?

Have you diff’d how the call looks when you make it in Postman vs in your application? Just to see if there’s any differences in what is being sent or how it is formatted.

hi Andrea, there is some config that is misconfigured in OKTA side. So now that was fixed and I am able to get the access token. but still after that also I am seeing session is not getting created are there further steps to create the session by using access token or how does it work because while redirecting to my app home I am still seeing as pre logged in page only instead of a logged in user.

What kind of behavior are you seeing within your application after the tokens are returned? If you’re using one of our libraries, what code do you have on the callback route? Is it designed to store these tokens?

well here is the flow and behaviour first on clicking on the hyper link on the login page of my app. it’s going to OKTA sign in page if I am not already logged in OKTA network let’s say if I am not logged in I will be redirected to OKTA sign in page to verify my cred’s after verifying it’s redirecting to the my app home page as I configured in my OKTA config. but still I am not seeing myself as a logged in state. in the network calls I can see my code is calling /authorize end point and getting code and state and I am retrieving that code and passing to /token end point along with other required params and it’s returning 200 success response as well. but still not seeing session is not being created and while redirecting from OKTA to my app page I was seeing as not a logged in user. Just a quick question in the OKTA config file for the redirect_uri param: do I need to add /callback at the very end as mandatory? not sure about that as of now in my redirect_uri I do not have /callback at very end.

How are you checking this? For example, if you are using our AuthJS or React libraries, are you using isAuthenticated?

Whatever you have as the callback route in your application should be the redirect_uri. For example, in our React sample app, the Routes are defined with the LoginCallback component on the /login/callback route, so the redirectUri in the config references the same path

<Route path="/login/callback" component={LoginCallback} />
const REDIRECT_URI = `${window.location.origin}${BASENAME}login/callback`;

If you haven’t yet, I highly recommend playing around with our sample apps, see if it works for your out of the box, and, if so, check what is different with between your app and the sample