Using OAuth 2.0 for Installed Applications - node.js

I am programming a command line tool (installedApp) that will need access to the Google Sheets of the user. For this I need to get an access token from the user.
I am following these guidelines OAuth2InstalledApp. So far I managed to get the authorization code by using the http://localhost type of redirect_uri. I specified http://localhost:7373/authorizationCode as the redirect_uri and I have a local server listening on port 7373.
But when I make the request to get the access token, I get an HTTP 400 Bad request response with a
redirect_uri_mismatch error
. When I make the request,the redirect_uri is defined as "The redirect URI you obtained from the Developers Console". Which is kind of wrong because when you create an Installed app you don't have the ability to specify a redirect uri (only with web apps). https://infinit.io/_/i48b2rM
So my question is what am I doing wrong?

When you create a client ID in the Google Developers Console, two redirect_uris are created for you: urn:ietf:wg:oauth:2.0:oob and http://localhost. Also you can consider urn:ietf:wg:oauth:2.0:oob:auto .The value your application uses determines how the authorization code is returned to your application. choose a redirect uri

Related

I'm getting a redirect_uri_mismatch when deploying my Node.js app to Heroku using Google OAuth2

I'm tasked with making a server using Node.js which will read emails from a Google account and parse the content from those emails into data we can store in a database. I'm using Google's googleapis package (v103.0.0) in NPM to authenticate/authorize with whichever account we'd like to use.
The issue comes when we try to switch accounts and have the user re-auth. During development on a local machine, the Auth process works as expected:
The client requests an Auth URL.
The server generates a new Auth URL and sends it back to the client.
The client redirects to that URL and the Google Consent Screen is shown.
The client is asked to choose between logged-in Google accounts.
The client authorizes the application and is redirected back to the server with a code.
The server uses the code to generate/save a token, which allows it to use the Gmail API.
However, after deploying to Heroku, the Google Consent Screen no longer allows the user to select an account. Instead, at step 3, it shows this message. In just about every other question related to this error, there's always additional information below the error code/message, but nothing's there for me. I made sure: (1) the domain I'm using in Heroku is verified on the Google Cloud Console, and (2) the redirect_uri within the Node.js application is passing the correct domain to the Auth URL, even while in production.
I can't provide the URL for privacy reasons, but let me know if there's any source code or Cloud Console info I should include.
It didn't take long after posting this question, but I realized I was using an incorrect OAuth 2.0 Client ID type. I was attempting to use "Desktop" when I should've been using "Web application" instead. Take a look at this image to see the difference.
When you select "Web application", you're given some new options: Authorized JavaScript origins, and Authorized redirect URIs. This is where you need to fill out the allowed URIs. Here's a sample of what that should look like.

"AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application" when signing in

I'm trying to follow this tutorial to create an app that uses the Microsoft Graph API, and I'm getting the following error when I click the "sign in with Microsoft" button:
AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: (the guid that is my application ID)
I added several URLs to the list of redirect URLs for my app at the Azure app configuration portal - one for another web app I want to eventually integrate this with (http://localhost:31503), one that was listed in the tutorial (http://localhost:44368), and the one that IIS Express is running the tutorial app as (http://localhost:7360). Even after adding all these URLs, though, I still get this error - what could be going on? Why can't I sign in?
There is a mistake in this tutorial. You should add https://localhost:44368/ on Azure portal, not http://localhost:44368/.
By the way, for the mismatch issue, there is a common solution. Just like #Marc said, you can track the auth request url to find the redirect_uri parameter. The request url is something like
https://login.microsoftonline.com/{tenant}/oauth2/authorize? client_id=6731de76-14a6-49ae-97bc-6eba6914391e &response_type=code &redirect_uri=http%3A%2F%2Flocalhost%3A12345 &response_mode=query &resource=https%3A%2F%2Fservice.contoso.com%2F &state=12345
After clicking sign in button and before inputting the account, you will find the request url.
Just look at the url your application is sending to AAD to request login. It will include url encoded reply_url parameter. Decode it and make sure your application is registered with exactly the same url: same casing, no extra/missing trailing slashes.

How can I get the Pinterest API to accept my redirect URL?

I am trying to build an app in node.js that connects to Pinterest via its API. I can get an access token via Postman and test my app in single-user mode, but I am unable to incorporate OAuth2 to test my app for a second user. Every configuration of my code and settings at developer.pinterest.com yields the error "The provided redirect_uri ... does not match any of my registered redirect URIs."
I registered what I believe are correct callback URLs at developers.pinterest.com--many variants, with and without trailing slashes. My callback is hosted via https.
I tried calling Pinterest's auth URLs OAuth2 in my server code (node.js), and via browser address bar.
https://api.pinterest.com/oauth/?response_type=code&redirect_uri=https://www.outfinterest.com/auth/pinterest/callback/&client_id=5042375080944909391&scope=read_public&state=true
I attempted the auth from a browser logged into Pinterest as me, and from a browser logged in as a registered tester of my app.
What must I do to get Pinterest to accept my callback URL?
Do I need to submit my app for approval before I can authorize via OAuth2?
I resolved the problem by reducing the set URLs registered at developer.pinterest.com to just the one I need, then reloaded the page with the app settings.

When registering an app on Azure Active Direct, what "redirect URI" or "Sign-on URL" should I use?

Might seem a silly question, but Microsoft's documentation isn't very beginner friendly, I think. It uses as examples "http://localhost:31544" for the sign-on url and "http://MyFirstAADApp" for the redirect URI, but although I understand what a local host is I can't figure out what exactly the numbers on it are and how I define them for my application, and absolutely zero clue of what the redirect URI is supposed to do for a native application and how should I define a URI for my own.
To be more clear on what kind of app I'm trying to add, I merely want to acess the Office 365 management API tools and get some data from it, so I imagine a native app would fulfill my needs for now. Registering the app on Azure AD is required to do so according to Microsoft's documentation.
So expanding on the title, how to define an URI for my native app is what I would mainly like to know. Some further clarification on what exactly is the purpose of this URI as well as to how to use and/or define a localhost URL for an Web app would also be much appreciated.
I know this is ancient, but I don't see a satisfying answer here, and maybe someone will come across this and find it useful. To answer the question asked, unless you're going to work outside of the default MSAL handling of the server responses, and I don't expect you would from your description, I'd just go ahead and use the default:
https://login.microsoftonline.com/common/oauth2/nativeclient
When you go into the Azure AD portal, go to your application and, from the Overview, select the "Set RedirectURL" option, you'll add a platform and select the "Mobile and Desktop Applications" and you'll be provided with the choice of 3 URLs to choose from. My understanding is this is just there for custom handling of authorization tokens and is telling MS where to send those tokens. The MSAL library functions seem to use this link as well, so they're probably handling this in the backend.
I agree with the OP though, the MS docs are severely lacking for newcomers and I wasn't able to find an end-to-end description of what needs to happen to get, in my case, a desktop application to send email through Office365 using 2FA. I would forge ahead as best I could until I hit the next error, then explore that, sort it, then slam into the next one. Rinse and repeat. This was made extra tedious as I had to go through a 3rd party IT group to get the 2FA access codes every time I wanted to test.
Best of luck, hope this helps someone!
how to define an URI for my native app is what I would mainly like to
know.
You should provide a Redirect URI that is unique to your application as it will return to this URI when authentication is complete.
In your application, you will need to add a class level variables that are required for the authentication flow, include ClientId and Redirect URI.
Here is the diagram:
Native application makes a request to the authorization endpoint in Azure AD, this request includes the Application IP ,Redirect URI and application ID URI for the web api.
After user signed in, Azure AD issues an authorization code response back to the client application's redirect URI. After that, the client application stops browser interaction and extracts the authorization code from the response.
Then the client app use this code to sends a request to Azure AD's token endpoint. upon successful validation, Azure AD returns two tokens.
Over HTTPS, the client app uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. The web API then validates the JWT token, and if validation is successful, returns the desired resource.
More information about it, please refer to this article.
For native you can set redirect to be equal to the Application ID URI, which now defaults to look like //app:{ApplicationId}
Redirect uri be starts with SSL URL, so select your project, enable SSL URL and use this auto generated SSL URL (for example : https://localhost:port#) as redirect uri , same to be updated in the azure app registration as additional redirect URIs

Standalone app authorization without browser?

Is browser redirection necessary to get autorization and access token ? Is there a way how to get autorization programatically ? I am a bit suprised i found this in the OAuth2 google documentation :
https://developers.google.com/accounts/docs/OAuth2#scenarios > Chapter Installed Application
sequence begins by redirecting a browser (either a browser embedded in the application or the system browser) to a Google URL with a set of query parameters that indicate the type of Google API access the application requires...
We run small java utility app which contains username and password in config file to our google account. i would expect there will be way to get autorization and access token without any browser interaction (it`s a bit hard to do when we run it as a cron job on virtual server)...
It's about trusted path between credentials holder (user), and authentication entity (it can by google app's server, or openID or facebook...). Someone who uses OAuth, provides his credentials to server he trusts, and in turn this server not revealing any secret data about him, provides identity assurance for your app.
So you have to provide trusted path to Oauth porvider. This can be done by opening a simple http server within your app, and opening user browser pointing to it, and then authentication would be done using, browser, and after auth is finished your server would recvive OAuth response and your app could authenticate user.
That's the idea, I would not input my "global" credentials to some app, and trust it that it will not, copy and use them later on. You've registered within specific OAuth provider and only he should know, and recive your credentials.

Resources