We Keep Coding

Need Google OAuth 2.0 Architecture Suggestion for Sending Smtp Mails via java mail Api

We have a Client Server Based Java Product, I need to integrate google OAuth in server dashboard where our client can sign in and allow access to gmail API. After that, server will use REFRESH TOKEN and ACCESS TOKEN to send Email reports to some emails Ids using client gmail Via Java Mail API.
We need to implement sign in only once and send mails forever i.e. Offline Access (Means REFRESH TOKEN is compulsory).
Our product is deployed as in premise as well as cloud based (At a time only one). Thus in client environment we can have private ip or public ip or public ip mapped to dns.
I know there are two way in which this can be done:
1) server side authentication
2) client side authentication
In Both cases you need public dns mapped REDIRECT URI ie a url where google will redirect the user after sign in. But in our case, we dont have
always a public domain mapped to client server machine. Also we cannot provide localhost in redirect uri as well.
SO
PROBLEM I: What should be used in place of REDIRECT_URI
PROBLEM II: We have many clients so should we use one application for each client or we should deploy a single application on cloud, where each client dashboard will be redirected while sign in and in response we will get token.
Any other alternatives for above problem will be appreciated.

Ok i got the architecture.
Google apps give the flexibility to add multiple java script origins and redirect uri's.
So we need to create only one app in developer console. For each client, we will add a authorized java script origin and redirect uri in google app online. And when sign in button will be pressed in client's server we will give redirect uri accoring to that client which is already added in google app. For private ip there is no solution, but localhost can be used with the restriction to sign in from browser on server system.

Is it possible to add headers for CORS at the calling side server?

I have a GWT appilcation in which the client makes a request to another domain.
I wrote the request using RequestBuilder in GWT.
On executing the code, I get an error in my browser :
No 'Access-Control-Allow-Origin' header is present on the requested resource.
So I google and I found that the domain to which I am making the request should add this header in the response that it sends. Now I dont't have control over the other domain's server, so I can't do any modification there.
My question is, can I intercept the response and the Access-Control-Allow-Origin header to the response that is being sent by the other domain's server at my server, before I send it to my client?
I tried using Filters but the Filter doesn't get called for responses coming from another domain.
Is this possible to do, am I missing something or is it just not possible?

Vivek's answer that cross domain requests aren't allowed by the browser is true, except for the CORS mechanism, whereby newer browsers that support it can try in a cross origin way to servers that also support it.
However, unless that remote server support it itself, there is nothing you can do. If I server my app from A, and want to connect to B, only B can authorize that. If A were allowed to permit my app to connect to B via some filter or servlet, then I could write an app that makes calls to gmail or facebook or twitter and read/write your settings and personal data at those other urls.
So instead, it is the cross origin server that you are contacting that must approve the connection with the header you mentioned. In lieu of that, you can still use your own server as a proxy for the cross origin server.

Cross-domain requests are forbidden by web browsers as per the same origin security policy. These restrictions are limited to browser based applications and hence you can definitely use your own server application as a filter between the GWT based client side application and the external server.

Finding the Requested Server Host Ip?

I have an application(client application) hosted in a Tomcat server and this application has to be integrated as a Tab in another application(parent application). In the Parent application the user authentication is done. in the Parent application Html we are using iframe to integrate the client. Everything is working fine except this. The Problem is, if some one knows the URL they can access the client application. How can we avoid this.? we are using JAVA,SERVLET,HTML,Tomacat as technologies.
Thanks :)

One of possible solution is token based authentication.
The parent application should add special token either as a URL parameter or as HTTP header. The token should contain authentication information in encrypted form. "Client" application should extract the information and decide whether authentication passed or failed. In order to guarantee that no-one can copy this token and then get unauthenticated access to your application you should make the token to be one-time or limited in time range.

You can also use x-frame-options in your header. I found this article with some quick googling: http://www.jtmelton.com/tag/x-frame-options/
This will prevent your app from loading in frames except for the domains which you allow permission. You might check into browser compatibility, I'm not sure when this was implemented in different browsers.
Also, you can check the 'host' and 'referrer' header fields to check that requests are coming from a domain you trust before sending a response.
OAuth is the standard for authorizing third party apps. You should check into that as an authentication approach.
None of these will give you a completely secure app. You should consider consulting with a security expert.

From parent application add cookie and from child application get that cookie and validate user.(if both are running on same domain).

Security Problem: For REST URLs and Static HTMLs

I have a design like that:
There is a core part runs Spring on it with REST.
There is another part which has a Tomcat Server and has just HTML files(not jsp or anything else.) So if I want to change a page at tomcat side there is no need to restart application also design and code part separated. Let's accept that I am listing users at my web side(tomcat side). Then my web side makes a GET request and response comes as JSON. PUT, DELETE and POST happens with same methodology.
I have 2 security problem at this point.
First, When a user wants to see an URL at server side how I will check authorization and authentication? And how can I limit an authorized person to get my web page with a too wget?
Second, How can I hide my REST URLs. For example if a user debugs my JavaScript code he/she will see that I am making a DELETE request to an URL with some parameters so he/she will try to do the same(or can make thousands of GET request to my core server if learns the URL)
Thanks for advices.

Firstly, why do you use Tomcat to serve static files ?
The approach I would take is this one:
use a static server to serve static files (apache, lighttpd, nginx).
This server will do authN and authZ (using an LDAP directory e.g. or any other suitable auth backend).
AuthN is done using scheme like Http Basic + SSL, Http Digest, WebID, ...
This is a solution to your 1st problem
Configure the static server to reverse proxy your app server and use the same auth rules.
URI are not "hidden", but they are no more accessible to anyone. Since the user is already authenticated to the static page, no auth should be necessary to request "rest uri".

Securing a REST API

I am in the middle of developing a PHP social media web application which will be supported by various web services each operating a REST API. Web services will probably be implemented in Java with MySQL data layer but the whole point of what I am trying to do is make it really easy to implement modules in different languages/data stores depending on what is approriate.
So for example when the user logs into the application via a login form the PHP code connects to a web service and POSTs the username and password to check if they should be authenticated. I would normally at this point start a session and store it in a session data store.
Another example could be if a user sends a private message to another user. The message would be POSTed to the private messaging web service which would take care of all the storage. Similarly the web service could be contacted to retrieve messages for a user.
Although I understand how to implement the REST web service in Java and make the connection to it in PHP I am totally unsure as to how to secure the data being passed and make sure that it is the users data being returned. If for example I want to get all of user As private messages how does the web service know to return that users. I could pass that users identifier as part of the GET url but then surely any old user could just figure out the GET url and use it to look up other peoples messages. I thought maybe I could pass over the session identifier and IP address which would allow me to check the session data store and make sure it is the correct user?
To secure the data that is important - like the username/password I thought I would just pass it over SSL.
Hope this explains my problem better.
Thanks

Take a look at HTTP Digest authentication. Most clients should support it, and it means the auth details can be passed securely with each request as part of the headers without interfering with the payload of the request itself.

I think requiring OAuth is a good choice. Your end users should appreciate that other websites don't need to ask usernames and passwords to access their data. As far as SSL, it's clearly worth doing if you can. You'll have to see if the performance trade-off is acceptable.

Keep in mind that your api must mimic the HTTP protocol.
Http is stateless, and by adding any Sessions or so, you're trying to fake an "Alwaysconnected" method.
With a LoginForm, it's like I'll have to send two requests for each calls ;)

These are basically 2 questions.
When privacy is a concern I'd go for the safest option: Serve data over SSL (via HTTPS).
As far as authentication is concerned, there are several possibilities. Basic over SSL is one of them, but a simple login form with a cookie can be another one. (ASP.Net Forms Authentication for example.) This all depends on how you want to implement your authentication mechanism.