Next.js 14 oAuth 2.0 authorization flow redirect 401 error

Hi @Greg-DB and @Здравко

Thank you both for your replies.

This is the first time I am implementing the Dropbox oauth 2.0 authorization flow so I apologise if my understanding or language is not precise.

What I am trying to achieve is for the app to interact with a user’s Dropbox account on the user’s behalf. I understand that an access token from Dropbox is required by the app in order for the app to achieve this. My understanding is that this access token is produced as a consequence of completing the Dropbox oauth 2.0 authorization flow.

If my understanding is not correct, I would be grateful if you were able to correct it.

Leaving aside for the moment whether my understanding is correct, what I have been able to achieve so far is the following:

1. The user indicates they want to allow the app to interact with the user’s Dropbox account on their behalf by clicking a button -> ‘Allow Dropbox access’
2. Upon clicking the button, the page is rerouted to `https://www.dropbox.com/oauth2/authorize?client_id=${process.env.NEXT_PUBLIC_DROPBOX_APP_KEY}&response_type=code&redirect_uri=${process.env.NEXT_PUBLIC_DROPBOX_REDIRECT_URI}&access_token_type=online`;
3. The Dropbox authorization flow appears. The user is given a choice to click on the ‘Continue’ and ’Allow’ buttons on the ‘Before you connect to this app…’ and ‘[name of app] would like to:’ pages respectively.
4. If the user clicks on both of these buttons, the Dropbox authorization flow disappears and the browser window goes blank.
5. A url similar to the following ‘http://localhost:3000/api/dropboxcallback?code=Ws4_UVwyTaIAAAAAAAAu9Cdym8LTtUw6RUcHUAP_pQk’ appears in the browser address bar (Callback Url)
6. A GET 401 Unauthorized message appears in the browser console tab
7. 

    

8. A 401 error appears on the second line in the browser network tab
9. 

    

10. If the Callback Url is executed manually, the logic located in the api/dropboxcallback api route executes successfully and an access token is created.

My question is: why is the Callback Url not executed automatically?

@Greg-DB you say I ‘need to check on what it is doing on its /api/dropboxcallback page’ – this page executes properly and successfully if the Callback Url is executed manually. This page does not appear to be being ‘reached’ once the Dropbox authorization flow has finished.

So therefore, why is this so? Why is being treated as ‘unauthorized’? If the answer to this question can be determined, then perhaps this will lead to the entire authorization flow executing automatically.

If you were able to provide any assistance as to why the Callback Url is being regarded as unauthorized, I would be very grateful.

Although I made a reference to ‘state’ in my original post, I believe I understand the purpose behind this better now and do not believe it forms part of the larger question as to why the Callback Url is being treated as unauthorized. However, I am very happy to be corrected.

I am very grateful for any assistance.