Exchanging a Dropbox authorization code for a re-useable access token with php and oauth2 - api

I am trying to exchange the authorization code I received without success. I am using the manual way where I omit the redirect url:
https://api.dropbox.com/oauth2/authorize?response_type=code&client_id=<key>scope=&state=<state>
when this url is activated it will take the user to the authorization screen, if the user authorized the app, it DOES NOT redirect, instead it prints an authorization code such as:
Enter this code into <app-name> to finish the process.
GooKWtwe54AAAAAAABABSUl_Ruv1COvpBBCuWQ5kv2g
How do I exchange this code for an access token?

If you're not supplying a redirect_uri parameter on /oauth2/authorize to automatically redirect the user, you can prompt them to copy that authorization code into your app manually. Then, your app should exchange that authorization code for an access token using /oauth2/token.
Also, note that /oauth2/authorize should be accessed on www.dropbox.com not api.dropboxapi.com, as it is a web page. The /oauth2/token endpoint is an API call, so that should called on api.dropboxapi.com.
You can find the documentation for both of these here:
https://www.dropbox.com/developers/documentation/http/documentation#authorization

Related

Redirect URL for authorization code--design flaw in spec

Friends, in the Authorization code flow, it states that after the /authorize call is initiated and success, the authorization code will be sent via HTTP 302 "redirect" URL to the client(say ReactJS webapp). Why the OAuth specification requires this to be sent in a redirect so the authorization code is sent in URL parameters exposed. I know it is recommended to use PKCE to handle this auth code leak issue, but my question is why OAuth spec requires us to send the auth code in 302 redirect in URL params in the 1st place. Why cannot the client(ReactJS webapp) place a simple GET request to the IDP and why cannot the IDP send back the auth code in the response body to the react JS application(say by xmlhttprequest). Any help is appreciated. Thanks.
If you use a OAuth2 service like Google, or some other service, and your react application would be able to handle the entire flow it means it can completely act on behalf of the user.
By requiring a redirect, it means that the user's own browser will go to the auth service's website, which is the only place the user can trust to safely enter their password and grant access to your application.
The URL in the addressbar means trust. Users are trained to never enter their password in a website they don't recognize.

How to get access token using oauth 2.0 authorization grant type in rest assured

I have an api with oauth2.0 authorization grant type authentication which has the following steps -
Get method for authorization code which opens up a form in browser where you need to enter credentials. This results in a series of post redirect requests and finally returns a authorization code in third post response header
Now a post request is sent, with grant type authorization code containing client credentials and the above authorization code we got from the get request, in the body and it returns the access token
This is how it works in postman. How can I achieve the same thing using Rest Assured?
You need two handlers
Handler 1:
To redirect to oauth server. (requeter should identity list of grant types, generate url with client_id and state and redirect application to this url)
Once end user signs in and allows the grant. (assumed that user allows)
Handler 2:
oauth server redirects back to postman with a authorization_code and state.
You need to configure redirect to your server callback url.
Once you receive these two
Verify state is same as what you sent. if yes proceed.
send authorization_code, cleint_secret, client_id back to server to recieve access_token and refresh_token
Use access_token to access data.
Use refresh_token to get new access_token.

What is the redirect URL for karate like the one we have in Postman?

Problem:
As per Auth0 below are the prerequisite for Auth0
Prerequisites
Register your app with Auth0. To learn more, read Register Regular Web Applications.
Select Regular Web App as the Application Type. (Done)
Add an Allowed Callback URL of https://YOUR_APP/callback. (This part I am not able to find and question is related to this that what is the call back URL in karate?)
Make sure your application's Grant Types include Authorization Code. To learn more, read Update Grant Types. (Done)
Below are the details how this Auth0 API will be authenticated.
Authorization API is called to generate code.
Token API is then called with the code generated at step 1 in order to exchange code for token.
Both of above APIs require a redirect URL of the calling application like we have in Postman as can be seen in below image. What is the redirect URL that can be provided in karate so once the token is generated it gets redirected to karate and token is shown there in response.

In gmail authorization, as per google doc how code can be generated by redirect url?

As per Google doc:
Handling authorization requests
When a user loads your application for the first time, they are presented with a dialog to grant permission for your application to access their Gmail account with the requested permission scopes. After this initial authorization, the user is only presented with the permission dialog if your app's client ID changes or the requested scopes have changed.
Authenticate the user
This initial sign-in returns an authorization result object that contains an authorization code if successful.
But could not get how handling authorization flow can occur? Is there an endpoint for it?
I got an answer,
request on:
https://accounts.google.com/o/oauth2/auth?client_id=*****.apps.googleusercontent.com&redirect_uri=https://www.msn.com&scope=https://mail.google.com/&response_type=code&access_type=offline&prompt=consent
Here, make sure you have specified scope in consent screen.
It will redirect user to give access of gmail scopes after that you will be redirected to msn url. url itself contains code which will be further used to get access token. code you get will be used one time only.

Exchanging code for access token fails when using Sign in with Google in Dropbox

We have an application that uses Dropbox API. When the user goes through the Dropbox OAuth 2 flow and signs-in using their email address and password, all works fine and we get the access_token. However, when the user uses the "Sign in with Google" flow in the Dropbox authorization dialog, we get back code which we then try to exchange for access token but the request fails with {"error_description": "code doesn't exist or has expired", "error": "invalid_grant"}.
Here's the steps we use:
1.
var dbx = new Dropbox.Dropbox({ clientId: clientId });
var authUrl = dbx.getAuthenticationUrl('https://www.dropbox.com/1/oauth2/redirect_receiver');
This gives us url https://www.dropbox.com/oauth2/authorize?response_type=token&client_id=...&redirect_uri=https://www.dropbox.com/1/oauth2/redirect_receiver.
2.
Open authUrl in a popup.
3.
User uses "Sign in with Google"
4.
We get a redirect to the URL below that contains the code:
https://www.dropbox.com/google/authcallback?state=...&code=...&scope=...
Now trying to exchange the code for access token with POST to https://api.dropboxapi.com/oauth2/token gives us:
{"error_description": "code doesn't exist or has expired", "error": "invalid_grant"}
The problem here is that, given the use of the Google Sign In flow, there are actually two OAuth authorization flow instances occurring; the Google Sign In flow is nested inside the Dropbox app authorization flow. Your app doesn't actually need to know about this though.
That https://www.dropbox.com/google/authcallback URL is Dropbox's redirect URL for the Google Sign In flow, and accordingly the code given there is for the Google OAuth flow, not the Dropbox OAuth flow. Attempting to use it for the Dropbox OAuth 2 flow will accordingly fail as you've seen (since it actually came from Google, not Dropbox).
You should have your app wait until your own redirect URL (in your shared code, https://www.dropbox.com/1/oauth2/redirect_receiver) is accessed, and only then take the code from there and exchange it for a Dropbox access token.