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.
Related
I've been struggling with this and would love to see if any OAuth experts here have an answer.
For context, I'm trying to integrate OAuth into an existing first-party (internal) front-end client that lives on a subdomain. It's a single-page application. I have an authorization server that has an /oauth2/authorize and oauth2/token endpoint and I'm working with the OAuth 2 with PKCE authorization flow.
In all the examples I've seen externally, it seems like the recommendation is to make a top-level redirect to the authorization URL initial login . And for silently re-authenticating a user (if they were already logged in), using an invisible iFrame set to the authorization URL (and postMessaging the code back to the parent window).
I'm trying to understand what prevents me from making a front-channel request to my /authorize endpoint via Javascript. Something simple like...
const { state, code } = await fetch(authorizationUrl)
For the login case, I can handle a 403 error back from the AS and then redirect them to login from the client-side. For the re-authenticating case (i.e. client has an expired refresh token but is still logged in), this is great because I just get a 200 response and the code back directly in the JSON body and I can use it immediately. There is no top-level redirect, no hassle of saving app state, etc.
It seems like as long as the AS is willing to return the { state, code } via JSON, this should work. This means that
The AS authorize endpoint must be configured to allow CORS on select origins. This seems okay in a first-party context since I know which origins I should allow.
The AS must be sent client credentials (session cookies) with the request (otherwise the AS would have no idea how to determine if the user is logged in). In JS, this would be as simple as adding credentials: true. As long as the cookie credentials have Same-Site: None and the cookie is part of the same domain (cross-domain would not work since some browsers disable cross-site cookie sharing nowadays!)
I feel like I'm missing something crucial here. But at the same time, my prototype is working, so I'd love to get some input from experienced folks here.
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
So here's my scenario. My user wants to integrate my app with basecamp. They click a link like: http://myapp.com/api/basecamp/enable/abc123xyz. The abc123xyz in this case is the users id. So my app then redirects to Basecamp to start the OAuth Process.
Once the user agrees to allow access, Basecamp redirects back to something like http://myapp.com/api/basecamp/complete?code=123456. At this point the "chain" to the user is broken, so I don't know what user this code is for. I tried using a redirect url of http://myapp.com/api/basecamp/complete/abc123xyz however basecamp rejects this URL as invalid, I'm assuming this is due to the redirect uri provided in the request not matching my registered app redirect url.
Any idea how I can pass something to github that they will pass back to me so I can associate the access token with the user requesting it be enabled? Github allows for a state property to be sent during oauth requests that are tied to a user and sent back with their requests so the user can be looked up in between request. Thanks!
So, after actually reading the docs, basecamp does support the state parameter, and with this my problem is solved.
This is from the google federated login description
"Once Google accepts the authentication request, the user is redirected to a Google authentication page. At this point the authentication sequence takes over. On successful authentication, Google redirects the user back to the URL specified in the openid.return_to parameter of the original request."
I assume my web app is responsible for the redirect 'to a Google authentication page' mentioned here? I dont see how google can make this redirect.
And If my webapp does the redirect, how do the openid request parameters get sent to google?
On reading some more, its only possible that once "Once Google accepts the authentication request", (I assume the requesting party gets a 200 http status), the requesting web application now adds the same parameters that had been posted to google login endpoint to a google authentication url and then redirects the user to this url
normally browser stores and adds authentication header automaticly after successfull authentication.
I have a XMLHttpRequest and added the authentication header for basic auth. No problem at all.
Then I try to send a second request to the same url that is basic http protected without adding manually the http request header to this request. Poorly it seems that the browser is not storing the authentication provided in request 1. My goal is to add the authentication handler transparently to every request that follows the first one (like a native browser do).
Any idea? Thanks.
Browser only storing authetication requested from user. So, if you send 1st request w/o authentication fields, browser will prompt user for auth this time, remember credentials and use it for next requests transparently.