Architecture for OAuth2 - BackendServer - FrontendServer

Question

I'm developing an whole ecosystem with an OAuth2 Provider, a Backend Server and a Frontend Server.

• OAuth2 Provider: provide only the authentication/authorization for the user, and a few other general purpose service.
• Backend Server: Implement all the logic and the models for a specific context, and is a OAuth2 client. Is registered on the provider and has all the right to use its APIs.
• Frontend Server: Expose a web GUI on the internet and get all the data from the Backend server.

By now, OAuth process works well, and after the authorization, the Backend server can get user data from the provider.

But I need to keep separation from frontend and backend , and I'm going to provide a RESTful API service accessible only from the frontend. My problem is HOW to do this in a correct and secure way.

I'm having some problem while I'm trying to make user authenticate in the Frontend using the OAuth provider session, and make it access to it's data.

This is some requirement:

• frontend need to access to OAuth2 user data through backend API.
• frontend and backend should be on different server, and could be on different host.
• on future I'll introduce more server that use OAuth service.

what's the best architecture for this needs?

UPDATE 12/10/2016

The HTTPS part is clear, I'll certainly use it.

I know the OAuth2 flow, but I'm not sure if you example fits my needs. Here's a really simple flow of a real use case. Suppose that the user is already logged in, and has already authorized the "Backend Server" (C). A request to B the html profile page, B need to retrieve the A's information from C using the REST API. C is the OAuth client, and have to be authorized from A to reade it's data. So C ask to D (the OAuth provider) the information, and all the data is returned back to B, that generate the html profile page.

My big doubt (and the reason of this question) is the follow: C is a RoR server that check if the session with the authenticated user is active before to manage the request. But when the request come from a server there's no session on the request, and even if B move the headers to C, C responde with an error, becouse can see that the session is note "clear".

My doubt is that I'm missing the correct way to handle the B-C comunications.

Answer 1

First, you will need **HTTPS**.

HTTPS = HTTP + SSL/TLS.

It creates a security layer on top of your HTTP and prevent a lot of attacks. For that layer to work you will need to trasmit and receive credentials in a form of an certificate. see HTTPS

HTTPS can be configured in One-Way or Two-Way.

One-Way: In the One-Way scenario only you send your server certificate to the client. He will verify it, and if it is ok, he will start the communication right away.

Two-Way: It happens after the one-way, but the client send his certificate to your server so you can get a chance to verify it. Only when you respond that you trust the certificate the communication will begin.

This is a configuration that you do on the servers. Your application/API will use HTTPS on your server to send/receive information.

Second, Here is a complete flow in OAuth2 with all steps.

In the picture above:

• User: Is the host (end-user or server) requesting something to you on you application server.
• Client: Is an application server that is connected to your Auth Server.
• Auth Server: Server that you OAuth Authentication Server is running.
• Resource Server: Is the API server used to access the user's information.

Once this flow is complete your 'user' is autenticated and have a token. By 'user' i mean user in an application or an api.

The 'user' then use the token in every request till the token expires.

In your case,

Your Rest Api will receive the token, in the Authorization header of the HTTP request rfc scpec link section 14.8 Authorization.

Authorization: Bearer mF_9.B5f-4.1JqM <- (token is here)

Then you need to check the token in your OAuth server to validate it.

This is happening on the last request between Client and Resource Server in the above picture.

GET /resource(access_toke)
200: response <- (token is valid)

If the token is valid then you can grant acess to the requested resource. If not you deny the request by returning a http status code of 401 (Unauthorized) see discussion on stackOverflow.

Third, you will need to protect your server against replay attacks.

see discussion on securityExchange.