I want to create a REST Api using NodeJS and make a request to some google apis(like gmail, contact and people api). I have created a project in google developer console and then enabled all necessary google apis in my project. Now when creating credentials(selected OAuth client ID), i am confused to choose the application type among 'Web application' and 'Others'. If i choose Web Application then what will be the value for Authorized JavaScript origins and Authorized redirect URIs
Note: I will be using this REST API for a chrome extension and an IOS app later.
https://developers.google.com/+/web/samples/javascript
states
"Note: Use a single project to hold all platform instances of your app (Android, iOS, web, etc.), each with a different Client ID."
Which means you would be fine selecting Web Application for your needs.
Related
I am looking into developing integrations for the Acumatica Cloud ERP. I am developing a SaaS product on Azure which extracts accounting data from various sources. From the documentation provided by Acumatica, I can see that the API connects to a local instance of Acumatica. If I were to connect to a local instance I would need to use some sort of gateway which connects to a local machine. I also had to install a local instance myself to be able to create a client application and use OAuth 2.0.
I am having issues to understand how to create integration with Acumatica.
Do I need to know the instance name / URL of each of my clients? Do I need to have a local instance running to be able to use Acumatica APIs? Can client Acumatica instances be publicly accessed? If the client using authorization code flow, authorizes my application to extract data from Acumatica, what is the Acumatica ERP URL that I should be using? Mine or the client's? The documentation always uses localhost to connect to an API.
If you use any of the Apis provided by Acumatica:
Contract Based REST (Recommended)
Contract Based SOAP
Screen Based SOAP
You only need the a set of credentials and the URL of the site to communicate with it from the outside. By set of credentials I mean that the credentials that you use need to be able to access and perform the appropriate action on the Acumatica screen that you want to integrate with.
You can find more information on how to do so on the help web site at the following link:
https://help-2019r2.acumatica.com/(W(12))/Help?ScreenId=ShowWiki&pageid=ff22837c-cd3a-410e-b768-88ca6e53b165
It is the Development Integration Guide
Edit
Since you are mentioning Authorization Code Flow in the comment, here is the link that contains more information
https://help-2019r2.acumatica.com/(W(14))/Help?ScreenId=ShowWiki&pageid=ff780860-09c2-46c9-bdd7-c6c3b1fc442c
On that screen you will see the following information:
After the user is authenticated in Acumatica ERP, the client application receives an authorization code, exchanges it for an access token, and then uses the access token to work with data in Acumatica ERP.
Which means that even if your application does not handle the user credentials, the users will need a set of credentials in order to connect the application to the Acumatica site. The user used here will defined the access rights that the application has.
I am creating two application :
1. Chrome extension for gmail.
2. It's IOS version
Now, since both the applications have same behavior and uses same google apis extensively, i decided to create a single project in google cloud platform for both. Now, when creating credentials, what will be my application type? I see both 'IOS' and 'Chrome App' under application type. Should i generate two Client IDs for chrome app and ios app?
To use single Client ID, i also tried creating a Node REST API (created a new project and set application type to 'web application' in google cloud platform) that will be used by both of my application to make request to google apis? But the authorization process includes, setting a callback url to get the authorization code and later use this code to get the access token. I guess this is not feasible for a REST API. Where should i keep the authorization part? In the application itself and later send the access token to my rest api? Is it possible?
I am very much confused about how should i start. Please could anyone suggest a better way to do this?
I generated two client ids, one for ios and for the web. Isolating both applications is a good way to start. Both the apps generate their own token id, pass the id to Node Rest API and later the use that token to make a request to Google APIs.
I am developing cordova based hybrid mobile apps targeted for android and iOS smartphones.
Usecase: The application authenticate user and then would be accessing Google Calendar API's, and finally display user events on the app.
Note: I will be Using 3-legged OAuth and Google Data APIs without the client libraries.
Question
The Cordova-enabled WebView provides the application with its entire user interface, so what should be the application type in this case?
Since everything is going inside webview, so Shall I choose "Web Application"?
OR
Do I need to create seperate Applications type for Android and iOS
seperately?
Or can iOS Application Type work for both Android and iOS?
Please suggest what should be the proper approach to choose application type in this case.
Thanks!
It depends on how your app is setup. If you plan on handling all of the OAUTH processing on a backend server then you can use the Web application type, and you can have all the OAUTH work offloaded to the backend server.
If you do not have a backend server and will do all OAUTH processing on the user's device, then you should create both an iOS and Android client ID. For example:
https://github.com/EddyVerbruggen/cordova-plugin-googleplus
This plugin's documentation shows the creation of both an iOS and Android client ID to enable Google Sign In on a Cordova app.
Is there a way to test my App service api app & Authentication using tool such as Fiddler? I used to be able to do this for Mobile Service by passing the token in the request header (x-zumo-auth). But now with App Service, it's no longer working or available.
Reason I ask is that my client won't be limited to those platform or will they be developed using those languages/SDK so I need a way to make REST API calls.
I am not sure about Fiddler, but I have used the Google Chrome Postman extension to do this kind of thing before and it works really well. It is free and you can get it from here (you'll need chrome installed): https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop
We are building an application with following attributes:
Consists of a web app, a web API, and mobile apps in future
The web app will contain HTML pages (multiple features that behave
like single pages applications)
The web app will talk to the web API (communicates in JSON, using
JQuery AJAX Calls)
The web app + web API do not follow the standard MVC architecture
Need to support SSO (will be using client Identity Provider) and
forms authentication
mobile will be consuming the same web API
My question is around what approach we should follow for securing the application. Two of the approaches that we are contemplating on are:
Securing the web API only: the web app is purely HTML and all the
data (that needs security) will come from the web API
For this, we thought of using OAuth for securing the web API
Both, the web app and the mobile app will first perform
authentication, generate an access token (follow the OAuth flow)
Securing the web app using forms authentication/SSO, and using HMAC
authentication for authenticating the API consumer (web/mobile app)
This delegates the user authentication to the consumers (web and
mobile app)
The API consumers will use HMAC for authenticating themselves
How can we pass the authenticated user details to the web API? Don’t
want to pass it as a parameter in API calls
Or is there any other approach that is better than the ones we evaluated above? Has anyone handled a similar situation where an HTML web app uses a Web API, and authentication happens using SSO + Forms/custom authentication?
If you have any comments agreeing/disagreeing the two approaches, that would be welcome as well.
We understand that the web app cannot be purely HTML, and some of the SSO authentication part will have to be handled on the server side and that is ok. But the core application will be HTML + Web API.
Here is some additional information related to this:
- Using ASP.Net with Framework 4.0 (with VS2010 IDE)
- Using Web API 1, but open to switch to Web API 2
You may benefit from building an external authentication/authorization identity management component in your architecture. Your current use cases can probably be covered by the tools that come with ASP.NET, but the architecture will be hard to extend as you start adding different types of clients and SSO scenarios. Look at this and this articles for a more detailed explanation.
Azure ID and Access management offering can be a good option. If you don't want to use the cloud, there are some third party and open source identity servers available.
Here is a good free book to help you understand federated identity concepts in the context of Microsoft technologies.