Say a SPA hosted in spa.com is loaded by user in user.com and uses oauth2 server oauth2.com for authentication through auth code flow (optional with PKCE). after user authenticated, oauth2.com would send the auth code back to the web browser and instructs it to redirect to the "redirect URI" registered with the app. now since SPA runs entirely inside the web browser, which can be anywhere, what the redirect URI should the SPA sent to oauth2.com to start with?
http://localhost : suppose to be just for local testing
its own address (user.com) : will not work since it is not registered
spa.com : SPA runs entirely in browser, not connected to spa.com
i know #1 and #3 do work but can't figure out why (#3). please advise what is wrong or missing with my understanding. thanks in advance!
The redirect URI for an SPA is usually the public URL of the app itself, so in your case this will be a value similar to one of these. On a developer PC this might be a localhost URL but I would think of it as a deployed URL and try to use proper domain names:
https://myspa.com
https://myspa.com/myapp
The technique for an SPA is then to see if you are receiving a login response as part of the main page load. See the call to handleLoginResponse in this source file of mine.
Related
https://learn.microsoft.com/en-us/onedrive/developer/rest-api/getting-started/graph-oauth?view=odsp-graph-online#step-1-get-an-authorization-code
I have followed this step to a tee, login with success, get redirected, and there is no code with the redirect url as the tutorial promises.
The following link is my version with the credentials.
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=a383dd3b-8306-4902-93d3-f5a33fe4a445&scope=Files.Read&response_type=code&redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient
I get taken to this page and sign into an account under the same namespace. Login view
After signing into a proper login, all I get in return is redirected to my redirect URI with no code attached to the end like the tutorial says I should. All I need is access to 3 files on my onedrive, but I can't seem to make it past OAuth2. Here is what I get redirected to. https://login.microsoftonline.com/common/oauth2/nativeclient
From first look it seems that the redirect_uri is wrong. This should be the endpoint where you receive the authorization code and then exchange it for the rest of the OAuth process.
I work with Pathfix and we solve the problem of OAuth token management using a serverless infrastructure.
To summarize, here is what your url should look like
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=a383dd3b-8306-4902-93d3-f5a33fe4a445&
scope=https://graph.microsoft.com/Files.ReadWrite.All%20offline_access&
response_type=code&
redirect_uri=https://your endpoint
An additional note on the scope. Note above that the scope definition for token should be as I have specified above
It all works the same. I just made sure my app was open to all tenants and replaced the .com with .us in all links but the redirect uri. Hopefully, this helps someone else. For example, my data is on a sharepoint, but the microsoft graph api works the same for all accounts with a difference in .us, .com, and few others.
First attempt at using the Imgur API for OAuth2 authentication. I have a Client ID and Client Secret from https://api.imgur.com/oauth2/addclient. The URL that is being called from my Vue application looks like:
https://api.imgur.com/oath2/authorize?client_id={CLIENT_ID}&response_type=token&state=test
...where {CLIENT_ID} is the Client ID obtained from the client registration. This doesn't work from my web app and also fails in Postman. I'm getting back a 404 which displays the page that reads, "Zoinks! You've taken a wrong turn."
Any advice is appreciated.
I had the same problem. For me the solution was to open my Vue application from the network address https://192.168.2.100:8080 instead of the local adress https://localhost:8080
Vue console picture
Imgur apparently doesn't accept requests from localhost. Consequently I also had to set the OAuth2 redirect url of my application registered in imgur to http://192.168.2.100:8080/...
Im trying to setup a groovy app where I'm trying to integrate a third party service. They have an OAUTH process where the user clicks on a button and is redirected to their site to login and "grant" my app access to their service (somewhat like facebook). BUT - They are then redirected back to the app with a user "code" in the url as a parameter, which is then used to get an OAUTH token on the user's behalf through a different endpoint. I'm having an issue getting the "code" on the redirect. can anyone help?
wwww.someurl.com?code=2l314jhlk13...2134lkj23h4==
how can groovy listen for the redirect? I don't know where to go from here and the service i am using dosn't have any documentation.
Depending on what service would you like to integrate.
In some of them you can skip redirect. Some of them provides SDK with ready to use solutions.
If nothing - you need to http server.
If you app is a plain groovy without any web frameworks, probably the simplest solution is to use JDK built in http server.
Example - http://glaforge.appspot.com/article/the-jdk-built-in-web-server-with-apache-groovy
I am investigating the possibility of integrating Box API calls from an internal application that sits behind our firewall (it is not exposed to the outside world).
So the question is, if we fire off an authentication request to Box with a callback URI, does Box post back directly to the specified call back URI (so essentially its initiating a new request from Box to the client), or does it send a request back to the client who made the request (standard HTTP request/response), and expect the client to redirect to the call back URI with the tokens?
This might sound an odd question, but during my investigation it appears this is how the Twitter OAUTH protocol works, and if so would help us a lot as we don't want to open up the firewall to the outside world.
See here for info: https://dev.twitter.com/discussions/5801
EDIT: Just found this which seems to suggest that the client will always initiate the request, never the server: https://stackoverflow.com/a/6116736/811108
Many thanks in advance.
A typical user journey for OAuth on Box would like like this:
User's browser requests www.someboxapp.com and the user clicks a login button
User's browser requests the Box authentication URL which begins with https://www.box.com/api/oauth2/authorize
User authenticates on the Box authorize webpage and then the Box site sends a 302 redirect header back to the users browser. This header tells the user's browser to request the the redirect_uri configured by www.someboxapp.com
User's browser requests the redirect URL on www.someboxapp.com - e.g. http://www.someboxapp.com/oauth/redirect_uri
The Box Application running on www.someboxapp.com makes a POST request to https://www.box.com/api/oauth2/token to complete the authentication and get an access token for using the Box API on behalf of the user.
What this means is that if you are running a Box web app on your internal network - you need to make sure that the webserver running the application and the users' machines can connect to https://www.box.com/api/oauth2/
If www.someboxapp.com only exists on your local network - that is fine - the Box API does not need to connect to this host.
Any way to test OAuth integration to google without having to have a port forwarding rule in my router back to my development Mac?
Background:
Developing Ruby on Rails web app that will request data from Google Calendar API via OAuth
Using Rails "OAuth Plugin" for this purpose
Developing on MacBook which is running my dev environment
Google needs (as part of OAuth) to make a callback back to my local dev environment
Can't seem to think of a way to test with Google without having to set a Port forwarding rule in my site's router back to my Macbook?
This threw me for a loop too. I actually went through the work of setting it up on a public IP even though I didn't have to in the end.
But yes, your comment is correct. The callback URL is passed on to Google during the redirect then after you've been authenticated with Google, Google will redirect you back to the callback URL providing an authorization code as a parameter.
The only server to server communication that happens is exchanging the authorization code for access and refresh tokens. This typically happens on the callback page. But since it's initiated by your server and not Google, no special open ports are required.