Develop Reference

Deploy my REST API's on AWS when the API's aren't supposed to be public API

I have an application which is built using Spring MVC and the backend is REST API also built using spring MVC framework.
The request from the browser first hits the springMvc app which then calls my REST API for data. I do not have any needs to expose my API's publicly. So I am not thinking to use any API gateway.
For security, am thinking to host my REST app in a private subnet and host the springMVC app in public subnet in a VPC.
My question is what if some developers would like to test the API's directly , what provisions are available in AWS to manage this in development environment.
I am using AWS cognito for authentication and am just going to validate the token in the REST app for additional security. At netwrok level, I am planning to use Netwrok ACLs to restrict the REST app to be only called by my springMVC app. Basically one public subnet and one private subnet.
Please help if my understanding is correct in this regards and would it cause any design issues later on.
If at some stage later, I plan to expose my API's to lets say a mobile app, I might have to do some rework. Is it worth it to think about future now and design accorindgly considering it might not take much time if I am on AWS.

You can use API Gateway to create private APIs that are only accessible by your VPC. You should consider using this option if possible. There are a lot of things that are difficult to manage when it comes to APIs such throttling, caching, and logging. Using API Gateway a lot of the scaffolding and instrumentation work for the API will already be done. You can also connect Cognito user pools to the API Gateway.
This blog post has a good overview and an example.

Different ways to secure RESTful Web service in java used by one or two clients only?

I have created REST web service in java but need to secure it so that only the authorised clients should be able to access the service. I have never implemented security before. Hence I have no idea where to start to be honest. Do I need to implement any token based security where client need to provide the token in the header of request and I need to verify on my end ?

As RESTful Web Services work with HTTP URL Paths, it is very important to safeguard a RESTful Web Service in the same manner as a website is secured.
For understanding of importance of security consider the following links:
http://howtodoinjava.com/security/restful-web-services-security-guide/
How to secure RESTful web services?
While for Implementation using Spring use the given link:
https://dzone.com/articles/securing-restful-web-service

Adding Oauth 2.0 to Jersey based RESTful server

I have a Jersey based server that I want to secure with OAuth 2.0. There are two paths that I've seen as common:
Oltu - Is compatible with Jersey and seems to be supported, although not as well as Spring Security. This 2012 question seems to suggest this is the way to go, but I want confirmation on a 2016 context so I son't implement something not as well supported anymore.
Spring Security - It seems to be very popular, but this path implies changing the server into a Spring based MVC. I don't know if that is something recommendable based on the benefits of using something as widely supported as Spring and the cost of the refactoring.
With support I mean a project that is in continous development, well established community with tutorials, materials and some libraries for clients (web, mobile, server) already available.
Which one is a stronger option? Is there another option or options?
In any case. Is there a good reference material or tutorial to start implementing this?
UPDATE
After few hours of reading and understanding about both the OAuth Providers I had mentioned, I feel Apache Oltu's documentation did not guide me much as there are key components that aren't documented yet, but an example gave me a better picture on how Oltu must be implemented. On the other hand, going through Spring Security's material I got to know that it can still be built on a non-Spring MVC based java project. But there is a limited exposure of implementations/tutorials on Spring Security on a non-Spring based project.
Another approach:
I came up with an architecture that might be more stable and would not care about the implementation details of the inner server(the one already implemented using Jersey). Having a server that is dedicated for security purpose (authorizing, authenticating, storing tokens in its own database, etc) in the middle that acts like a gateway between the outside world and the inner server. It essentially acts a relay and routes the calls, back and forth and ensures that the client knows nothing about the inner server and both the entities communicate with the security server only. I feel this would be the path to move forward as
Replacing with another security provider just means plugging out the security server implemetation and adding the new one.
The security server cares nothing about the inner server implementation and the calls would still follow the RESTful standards.
I appreciate your suggestions or feedbacks on this approach.

Apache Oltu supports OpenID Connect but its architecture is bad. For example, OpenIdConnectResponse should not be a descendant of OAuthAccessTokenResponse because an OpenID Connect response does not always contain an access token. In addition, the library weirdly contains a GitHub-specific class, GitHubTokenResponse.
Spring Security is famous, but I'm afraid it will never be able to support OpenID Connect. See Issue 619 about the big hurdle for OpenID Connect support.
java-oauth-server and java-resource-server are good examples of Jersey + OAuth 2.0, but they use a commercial backend service, Authlete. (I'm the author of them.)
OpenAM, MITREid Connect, Gluu, Connect2id, and other OAuth 2.0 + OpenID Connect solutions are listed in Libraries, Products, and Tools page of OpenID Foundation.
**UPDATE** for the update of the question
RFC 6749 (The OAuth 2.0 Authorization Framework) distinguishes an authorization server from a resource server. In short, an authorization server is a server that issues an access token, and a resource server is a server that responds to requests which come along with an access token.
For a resource server, API Gateway is one of the recent design patterns. Amazon, CA Technologies, IBM, Oracle and other companies provide API Gateway solutions. API Gateway architecture may be close to your idea. Some API Gateway solutions verify access tokens in their own ways (because the solutions issue access tokens by themselves) and other solutions just delegate access token verification to an external server (because the solutions don't have a mechanism to issue access tokens). For example, Amazon API Gateway is an example that delegates access token verification to an external server, which Amazon has named custom authorizer. See the following for further information about custom authorizer.
Introducing custom authorizers in Amazon API Gateway (AWS Blog)
Enable Amazon API Gateway Custom Authorization (AWS Document)
Amazon API Gateway Custom Authorizer + OAuth (Authlete article)
If an authorization server provides an introspection API (such as RFC 7662) that you can use query information about an access token, your resource server implementation may be able to replace (plug-out and add) an authorization server to refer to comparatively easily.
For an athorization server, gateway-style solutions are rare. It's because such a solution must expose all the functionalities required to implement an authorization server as Web APIs. Authlete is such a solution but I don't know others.

I think, it's far simplier to use the oauth connectors that are implemented inside jersey itself!
Have you considered using jersey own OAuth (already linked inside jersey) server / client ?
https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/security.html#d0e13146
Please take a look to :
16.3.2. OAuth 2 Support
hope helped. :)

Building a new Application: Java jax-rs ee6 restful web service with a html5 front-end using backbone.js

We are currently evaluating building a new web-application which consists of the following technology:
Back-end:
ee6 jax-rs restful web service
Front-end:
html5 UI using backbone.js (and various other libraries)
The question is, what is the best way to implement a secure session? Limitations are we cannot use oAuth (due to legacy login service we will be consuming). We need a financial industry level of security.
We are thinking about using HTTPS basic authentication with the rest server (back-end), and use backbone.js's session to elegantly handle the front end.
What are the security implications of adopting this strategy?

When you approach security issues, you must remember that your security is as strong as your weakest link. I hope you fully realize you need to secure all your communication, and not just the login.
Also, what key length are you going to use? 128bit?
I would recommend you to check about SPEGNO .. I think this might assist you.

Java and Spring back-end with Ruby (RhoMobile) front-end security

I am currently building a mobile application using RhoMobile. The application will simply be calling a bunch of REST web services. The back-end REST services are written in Java + Spring. I was wondering what the security considerations are. Our requirements are very simple, we need a secure way for a user to log in with the application, and only then be able to call the web services.
Does anyone have any experience with marrying these technologies. And what are my options. At the moment I am looking at either using Spring Security or Shiro, but just wondering if anyone has better experience.
Just as a note, we will be using JSON for all communication.

I have my backend web server running a Ruby On Rails application.
I communicate using JSON and HTTP Basic Authentication. In this type of authentication it is needed only to pass a header with the user name and the password encoded.
It is not the best way to achieve security, because if someone is monitoring your network traffic he could discover your credentials, but it could be a simple solution.