How to prevent someone just taking my API keys from the client side javascript code and starting to use my HERE subscription for some other use.
I noticed HERE provide an option to secure the API keys for a certain domain on the applications management page: "Secure app credentials against a specific domain". I have set up this option and also put domain there but I do not see any change on my app behavior.
The application still continue working fine on my PC. Shouldn't the HERE API stop working as web server is running on localhost and not on the defined domain.
My app is running fully on browser, and only static files come from the server (http://localhost:8083/index.html). I am using the HERE javascript API.
I tested also running the app on external cloud service on different domain than localhost. Results are the same. My conclusion is that the setting "Secure app credentials against a specific domain" just has no impact and does not work. Checked also the api response headers and all origins are accepted.
Access-Control-Allow-Origin: *
In your HERE dashboard, you can set the application id and application code to only work on a particular domain or set of domains. If the tokens are fixed to a domain, it won't matter if someone takes your tokens because only the listed domains can use them. If you don't secure the tokens to a domain, then someone will be able to use your tokens if they find them.
Related
In the HERE platform, I added an App under Apps in the Access Manager. I then generated an API key for this app. This API key works when using it on our webapp.
However, when I add a "Trusted domain" and "Enable trusted domains", the key no longer works. I added all variations of our domain:
sub.domain.com
https://sub.domain.com
domain.com
I have waited multiple hours between different attempts and it still doesn't work. When I disable trusted domains, it works again...
The following question seems related but there is no solution: HERE Maps specific domain feature not working
Is this feature not working properly, or am I doing something wrong?
you would need to pass the "Referer" + Your trusted domains in the header.
Example: If you have your IPV4 address in the trusted domain and use some tools like postman to test it. Then add Referer and the IP in the headers. It should work. Thanks
I have a separate frontend (single page application) which is utilizing HERE places API autosuggest feature. However, rest of the application logic which accesses HERE REST APIs is located at the backend side. These services are located on different cloud instances.
I can protect the API credentials by using the frontend SPA domain in "Secure app credentials against a specific domain" in the HERE project page. This blocks the API usage from the backend side. Is there a way to protect the credentials against both services?
You can try the HERE Serverless Apps approach. They provide security of AppID and AppCode: because it is in a central cloud Serverless Application being copied and used in every client application. Read more about it here https://www.here.com/en/aws-serverless.
Update: If you are not able to use Serverless, you can also add up to 10 allowed domains in your project in developer site.
I bypassed this problem by creating separate projects for frontend with domain limits and backend without.
Not an elegant solution, but it works, it's simple, and if I have to block a project in case someone hijacks the keys (everything sent through browser can be read by users) it's just some dynamic maps that wouldn't work until I update the site. Everything else is routed through the server.
I have an Intranet authenticating by Azure AD - located at https://intranet.example.com/ (In details, its Sharepoint Online);
In some pages, we need dynamic content generated by an rest api - located at https://api.example.com/ (In details, .NET WebAPI, Owin middleware using OpenId);
api.example auth by AAD too;
Both api.example and intranet.example have Windows Azure AD permission granted through admin consent;
api.example has X-Frame-Options, Access-Control-Allow-Credentials and Access-Control-Allow-Origin enabled to https://intranet.example.com/;
What I need:
Some pages have dynamic content generated by JavaScript logic requesting data from api.example;
Users will authenticate in intranet.example and api.example must have Single Sign On behaviour.
Avoiding any type of prompt or authorize request is a MUST, since all of that must be transparent to the final user;
What I tried:
I tried to simply put an IFrame inside intranet.example pointing to app.example and it works both on Chrome/Firefox. But, IE11 doesnt allow it, since my app redirects to https://login.microsoftonline.com/ that responds with X-FRAME-OPTIONS set to DENY.
Example:
User log in Google Account, access https://mail.google.com/ and have hangouts messages up and running with no prompt or authorize request or something else, totally transparent.
User log in Microsoft Personal Account, access https://onedrive.live.com/ and have Skype messages up and running with no prompt or authorize request or something else, totally transparent.
Note1: It must works outside our domain. So, setting Intranet/Trusted Site Zone is not a option.
Note2: The more decoupled from Sharepoint, the better.
Note3: I tried this aproach PnP Webcast - Calling external APIs securely from SharePoint Framework.
I would recommend re-posting your question in SharePoint Stack
Exchange.
AadHttpClient might be a better option, but it's in preview right now and 'not supported in production tenants'. It also requires the new SharePoint Admin Center which is only available for first release tenants.
Also, I found these to be better AadHttpClient tutorials than the existing MS documentation:
https://www.spdavid.com/consume-a-secured-azurefunction-using/
https://github.com/SharePoint/sp-dev-docs/issues/1378
Background
I want to create a PHP application that eventually will be installed on a "countless" web servers.
The application is going to access the Google Drive associated with the web server's administrator Google account (it will basically write some files on user's cloud storage). So my PHP app will be authorized by the end-user to use its Google Drive storage. This is done (via the OAuth2 protocol) by connecting the Google OAuth2 service.
So basically I have to create a ClientID/Secret pair (on behalf of my Google Account) that is gonna be used to execute the authorization flow.
Google provides 3 authorization methods:
for web applications (web browsers over network)
for service account (my server to Google server)
for installed application (like Android, IPhone)
(1) is perhaps the best choice EXCEPT that I have to define a REDIRECT_URI where the authorization code will be sent. Because my APP will be installed on a "countless" different servers I don't know in advance the protocol, domain name and the path (also the URI) where the Google's response should be returned. If I would install this application only on 3 servers I could create upfront a ClientID/Secret pair for each of them. It's not the case.
(2) means to deploy my P12 private key with the PHP application and I don't feel comfortable with that!
(3) means to put the end-user to copy/paste an authorization token from a Google web page into my application web interface. I am trying to avoid doing that.
I already made it to work by using the method 1 when I know in advance the REDIRECT_URI. I also embedded the client_id/secret pair in the source code so the whole authorization process is user-friendly. But this is not going to work on a "countless" deployment scenario.
Questions
Which method and how should I use it in order to make the whole process safe for me (as developer) and for the client too (the web server administrator). Note that the authorization process should not involve the end-user to copy paste some codes. I want that step to be transparent/user-friendly for the end-user (no one likes copy-paste when it can be done automatically).
Should I embed my client_id/secret into the application or that's totally wrong? I suppose no end-user wants to go through the creation of its own ClientID in Google Developer Console, right? On the other hand why I would give my client_id/secret to an unknown end-user?
Final thoughts
I could create a proxy application on my (the developer) web server such that my PHP application (which is supposed to be deployed "everywhere") will send the authorization request to my proxy server (which has already its own client_id/secret) which in turn will redirect the call to the Google OAuth service which then REDIRECT_URI back the authorization code to my proxy and finally I will redirect back the response to the original sender (the PHP application). What do you think?
Some useful answers here and here or here.
#Edit: as I've already said earlier a proxy would be a solution. I've made it and it works. The same solutions I've received also from user pinoyyid. Thanks for your answer too.
A proxy is the only real option open to you. You can encode the originator URL in the "state" parameter, so that when the proxy receives the access token, it can call a webhook at the originator.
There are some contradictions in your question...
"The application is going to access the Google Drive associated with the web server's administrator Google account" and "So my PHP app will be authorized by the end-user to use its Google Drive storage." are mutually exclusive.
If the Drive storage belongs to the app, then the user isn't involved in any OAuth dialogue.
Could you edit your question to be clear who is the owner of the Drive storage as it greatly influences the OAuth flows.
I'm having a similar problem as was discussed in this question:
authClient.login returning error with "Unauthorized request origin"
I can't find anything on the firebase site that directly addresses this problem so I have 2 questions about the "unauthorized request origin":
1.) If I'm testing my program through my own computer (as in, it's just a file on my computer), what exactly am I supposed to add to the Auth panel? I tried following the advice offered in the link above but no luck.
2.) My eventual plan is to create an app using firebase and it's login system. Is this going to be a problem for when users try to login? Is there going to be something that I need to allow so that any user will be allowed to login to the system?
With the release of Firebase Simple Login, which contains a number of OAuth-based authentication methods (Facebook, Twitter, GitHub, etc.), we included the idea of 'Authorized Origins'. Without this restriction, malicious sites could pretend to be your application and attempt to access your users' Facebook, Twitter, etc. data on your behalf.
By restricting the domains for these requests to ones that you control and have verified, we can protect your users' data. Once you have configured your application domains, your users will be able to log in seamlessly and securely from the domains you defined.
To fix this error, log into Firebase Forge (by entering your Firebase URL into your browser), and navigate to the 'Auth' panel on the left.
For testing locally, you'll need to run at least a barebones webserver on your machine, rather than loading your test files via file://. The easiest way to run a barebones server on your local machine is to cd to the directory of your files and run python -m SimpleHTTPServer, which will allow you to access your content via http://127.0.0.1:8000/....
For your users, configure the domains that you'll be using to host your application. This can be any number of specific subdomains (such as a.b.www.domain.com) or high-level domains which will act as a wildcard (domain.com will allow requests from *.domain.com).
You can configure multiple application domains or IPs here, comma-delimited.
See https://www.firebase.com/docs/security/simple-login-overview.html for additional documentation about application configuration for Simple Login.
I hope that helps! Feel free to ping me directly if you have further questions.