I would like to call /search api from javascript client side. To do so, I have read that I need a oauth2 access token.
Following the Google guide, I must go to Google cloud Console but there is no Google Cloud Print service to subscribe to.
What service should I use to obtain an API key?
I recently started getting familiarized with both Google Cloud Print and OAuth, so I don't know much. I started in the same way that you seem to be starting. That is, by trying to make a successful request to /search. I will describe what worked for me.
After creating the project in the Cloud Console, I went to APIs & auth > Credentials menu item and created a new client ID for a 'Web Application' application type.
For the created client ID, I modified the Javascript Origins and the Redirect URIs appropriately.
Then, I added an anchor to the following URL in my web application so that the user gets directed to the authentication page.
https://accounts.google.com/o/oauth2/auth?
response_type=token&
client_id=<application-client-id>&
scope=https://www.googleapis.com/auth/cloudprint&
redirect_uri=<application-redirect-uri>
client_id - should be the client_id value of the Client ID that you registered in the Google Cloud Console.
response_type - This value would depend on what kind of application are you planning to develop. For client side applications (JavaScript apps), token should be the value. See https://developers.google.com/accounts/docs/OAuth2 for more info on this topic.
redirect_uri - should be the redirect URI value that you specified in the Client ID that you registered in the Google Cloud console. This is where the user will get redirected when it gets authenticated.
scope - I set it to https://www.googleapis.com/auth/cloudprint. This value will request that your app be given access to manage the cloud printers associated with the user account that is being authenticated.
Now, the part where I got stuck is when trying to make the HTTP request using JavaScript (AJAX) to https://www.google.com/cloudprint/search. I get the follow response when I attempt to make the HTTP request to /search.
OPTIONS https://www.google.com/cloudprint/search No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.
It seems like the entity (server(s)) that is handling the request to the /search interface is not configured to use CORS? Correct me if I am mistaken.
Now, the way that I verified that I was able to successfully authenticate was by attempting the request to /search in a Java program instead. I used the OAuth token that I got when authenticating using my web app in a java program and made the request with the Authorization: OAuth <token> header set) and the request was successful.
Related
I'm using google calendar API to add the event to calendar. I was wondering if it would be security issue as I'm using client Id and API code in JS which can be exposed to someone using the application?
Also, if it is the case how to secure those keys?
PS- Docs that I'm following- https://developers.google.com/calendar/quickstart/js
Have you noticed the redirect uri? THe redirect uri tells googles auth server where to return the access token.
Even if I grab your client id and client secret. I cant use it because the server is going to send the access token to the redirect uri to your server.
This is why you should not set localhost as a redirect uri. 😉
RFC oauth2 redirection endpoint
After completing its interaction with the resource owner, the
authorization server directs the resource owner's user-agent back to
the client. The authorization server redirects the user-agent to the
client's redirection endpoint previously established with the
authorization server during the client registration process or when
making the authorization request.
That being said you should try to keep these keys private you should not share them or add them to open source projects. However Client sided applications like javascript is a gray area.
I am building a web app with the following properties:
The Front-end is based on VueJS
The Back-end framework is still not confirmed but it will be a RESTFul API
The users for the app will be authenticated by Azure Active Directory (AAD)
Here's what I have done so far:
I have set up a Web App/API in my AAD. Along with that following the guidelines here, I have completely secured my VueJS app and now I need to be logged in into my AAD in order to be able to use the app.
The problem now is that, the front-end is secured. But what about the backend? I am trying to get an access_token from the AAD which I can then use as an authorization header with every request to my backend later on.
Here is what I get from my AAD when I sign in using the AuthenticationContext from the adal library.
As you can see I am getting an id_token and when I use the acquireToken function of adal I get an id_token again.
Is there anything I am doing wrong here? Do I need to create another Web App/API on Azure?
How do I go about this?
Thanks!
According to official documentation and this might be your case.
"The OAuth 2.0 implicit flow in Azure AD is designed to return an ID token when the resource for which the token is being requested is the same as the client application. In other words, when the JS client uses ADAL JS to request a token for its own backend web API registered with same App ID as the client, an ID token is returned and cached by the library. Note that in this case the resource should be set to the App ID of the client (App ID URI will not work). This ID token can then be used as a bearer token in the calls to your application's backend API."
You can find more about this here!
https://github.com/AzureAD/azure-activedirectory-library-for-js/wiki/Acquire-tokens
Goal
I am trying to implement a server-side authentication.
I want to request authentication code using javascript on my website, and then pass the auth code back to my server. Then my server can use this code to exchange for refresh token, and access token.
What I have tried
I followed these instructions, and registered my Web application for client ID. It's working perfectly fine, but this is only for client-side authentication, and it returns a access token directly. Then I registered server account for another client ID, and replace the old one with the new one. I was expecting it returned authentication code, but it returned error in the Web console.
Error message
Load denied by X-Frame-Options does not permit cross-origin framing.
Question
Did I use the code in a wrong way, or my registration process might cause the problem?
In this website,
there's no mention of any build-in function for getting the authentication code. Do I have to implement it from a very basic level?
I am developing applications on Google App Engine, and am looking into the OAuth2.0 details. My question is the following: if a hacker intercepts an OAuth2.0 access token, can he fake requests from one of the "Authorized JavaScript Origins" defined in the Google Cloud Console?
A bit more details if it is unclear: in the Google Cloud console, you can define a OAuth2.0 client id which you send with your javascript using Google's JS api (complete flow here). Part of the process is that you get an access token, which you then use to authenticate subsequent requests. As an extra layer of security, all requests need to come from a specific origin that you define in your cloud console (see image). So only requests from that domain are accepted.
But I am wondering, if a hacker did know to get hold of an access token from one of my users, the request would still need to come from the authorized origin.
Can that hacker then go to https://myapp.appspot.com, tweaks the javascript with for example chrome Javascript Console, and use the access token from the user to make malicious calls as if he was the user he stole the token from?
As I see it, then the request is coming from an authorized JS origin, and with a valid OAuth2.0 access token. What am I missing?
In the case of OAuth2.0 in appengine, the user is just giving the consent to the application to use the services oh his behalf only. But the real communication is between the JavaScript app which is running on the AppEngine and the Service Provider. User is not included in making the calls it is the app which makes call to the API on behalf of the user.
Please going through the below link to grab the whole concept
https://developers.google.com/api-client-library/python/guide/aaa_oauth
The Problem:
Serving a secure API to a client side app using only a local authentication strategy. The red arrows are part of the knowledge gap.
Context:
That is --- client.example.com is making a POST to api.example.com/login where on success client.example.com can gain access to a GET service like api.example.com/secret.
An idea!
Implimentation of OAuth 2.0 with hybrid grant type sitting in front of API.
Why hybrid?
It wouldn't be an Implicit Grant Flow aka Client-Side Web Applications Flow because there is no redirection to API server too grant access token. (i.e.) "Is it ok for so-and-so to access your data?"
It wouldn't be a Resource Owner Password Flow because a Client ID and Client Secret are passed along with the request so it's assumed the client app is server-side.
OK... so what about a little bit of both?
What if we used a CRSF token on page load of client-side app, and POST it with user credentials too OAuth 2.0 authentication endpoint to exchange for access token? You would authenticate each subsequent request with the access token and CRSF token after a successful login.
A good Node.js OAuth 2.0 library I found:
https://github.com/ammmir/node-oauth2-provider
Help Me!
I can not find a working example of an authentication measure that solves this problem! Point me in the right direction?
Ultimately, the goal here is too authenticate a client side app to a REST api using CORS with a local strategy --- i.e. username & password --- even if the convention above isn't possible.
To Accommodate Bounty:
This is a client side app, so let's stay trendy.
I'm looking for a working example using the Node.js OAuth 2.0 seed above for the API/Auth server and a front end framework like Angular.js or Backbone.js to make requests.
The example should match the context described above.
I'm working on an app with a pretty similar architecture though the services are .NET Web API rather than Node and we're using DotNetOpenAuth for the OAuth provider. Rather than the hybrid approach you're suggesting we're doing the following:
x.com serves up a login page
login page POSTs back credentials to x.com
server side logic at x.com combines client_id and client_secret with the credentials to submit a token request (resource owner password credentials grant that you've
mentioned above) receiving back both a temporary access token and a
refresh token
the refresh token is encrypted into a cookie issued by x.com
both the cookie (with encrypted refresh token) and the temporary access token are then sent to the browser
the client app (angular in my case) can now use the access token to hit api.x.com for services (It appears you're well aware of the limitations of CORS... we hacked a version of angular's $resource to facilitate this but it wasn't pretty since we wanted to use all HTTP verbs and support IE9)
when the access token expires, the client side app can request a new access token from x.com
server-side, x.com decrypts the cookie to get at the refresh token and issues another oauth call for a new access token
This is fairly high-level but hopefully gives you a sense for how to tackle your situation. In my case, and it appears in yours, we didn't want to use session state or a database to store the refresh token but obviously exposing that to the browser introduces security concerns so the encryption of the refresh token is important (among other security considerations) and the use of the cookie eliminates the need for session state or other persistent storage on x.com.
Not an answer running for the prize. Just my 2 cents :)
On my web server,
I do my authentication through a rest call with login/password with basic authentication over https. This call delivers a key to the client (a one page web app).
Then every subsequent REST call is signed with the key. The server checks that the signature is correct and everything still happen in https.
This mechanism is quite used I believe.
I don't see the issue with cross domain. I have a single source anf if I need something from another source, I'd use JSONP.
I use nginx as an https->http forwarder.
Not sure how it competes with an OAuth2 solution.
I've built this example using Node and PassportJS to show how to authenticate the users with Facebook or Local Strategy. Both sides are on different domains as you described and it requires CORS enabled.
GitHub: https://github.com/pablodenadai/Corsnection
Live demo: http://corsnection-client.herokuapp.com/
I can't promise that I have time to write working example but I can show you 2 paths :)
The biggest deal is CORS. After you solve that problem it is easy to use $http service. So, first and probably easiest may be to configure reverse proxy in x.com webserver which points to api.x.com. I wrote article here
Second approach is better, and created for exactly this purpose, to authorise specific domain to use your resource. It involves a bit of coding in api.x.com so you don't have to change anything in new web applications served in other domains. You simply need to authorise CORS requests in api.x.com service.
Create table in database where you can manage list of authorised domains
Add in that table record "x.com"
in api.x.com add request filter/interceptor what ever tech term you use for method which should be invoked after request is handled and add in response Access-Control-Allow-Origin: x.com if request comes from x.com (in other words check in request header refer value match to any value in table above and put that value in Access-Control-Allow-Origin response header).
That is all :) After this if you know how to use $http or jQuey.ajax you will be able to POST/PUT/DELETE/... any request to api.x.com from any authorised domain in just few minutes.
I very similar idea using vinilla js web app and cross domain authentication to GAE backend or OpenID connect.
The web app is run on CDN. When click login link, it goes to respective login server and redirect back to the web app (with XSRF security token and HTTPS only cookie). Login server accept cross domain request with credentials. XSRF token has to be set (in header) with every request. cookie is set by the browser. Since it is HTTP only cookie, JS cannot read it. The technique is very secure.
Once login, you can get secure assess from login server.
For detail description, you can find here and open source repo here.