Some new code we're building at work requires two back-end services to communicate with each other as well as a 3rd service that delivers content to the front-end. Obviously, this all needs to be secured and encrypted. Functionally, the front-end service uses one of the back-ends to verify user identity, the other back-end to store and retrieve site content, and the two back-ends need to communicate occasionally as well. The back-end services have no front-end interfaces at all, being REST services and delivering straight JSON or UBJSON.<p>I had thought that OAuth2 might be the way to go, but the spec is, to say the least, confusing. It also seems designed more for front-end sites to communicate through a back-end channel (eg. Facebook and Twitter), requiring a client-side redirect so the user can authorize the connection.<p>Oauth, on the other hand, doesn't seem designed with that redirect in mind, but it will be the "old" tech in a year and I prefer to not have to rewrite the authentication system then.<p>Public/private key is the way Amazon does it, and it's simple to implement, but there is a pile of articles telling me to use OAuth instead.<p>So, finally, the question is: with OAuth2, is it "legal" to hide the interaction from the user completely - the three services can communicate securely without the end-user being aware of the existence of the services. Specifically, the user logs into the front-end website, it can check Back-End #1 to verify the user's identity and return his information, then call Back-End #2 for the content that needs to be displayed for the current page. The user is not redirected and does not see any popup requesting authorization.<p>Thanks HN!