Architecture for OAuth2 – BackendServer – FrontendServer

client-serveroauth2web services

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.

Best Answer

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.

Related Solutions

OAuth2 flow – does the server validate with the Auth server

Found it. Buried in the spec. They say the resource server should validate the access token with the auth server but that it's outside the scope of the document. Pity, I would have thought that token validation was an important part.

Circular dependency in microservices architecture for Authentication

Before you do anything else, you should read this introductory article on HTTP authentication to get started.

Oath2 protocol flow is shown below as described in The OAuth 2.0 Authorization Framework:

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

                 Figure 1: Abstract Protocol Flow

The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
interaction between the four roles and includes the following steps:

(A)  The client requests authorization from the resource owner.

(B)  The client receives an authorization grant, which is a
     credential representing the resource owner's authorization

(C)  The client requests an access token by authenticating with the
     authorization server and presenting the authorization grant.

(D)  The authorization server authenticates the client and validates
     the authorization grant, and if valid, issues an access token.

All the resource services need to be able to validate the token. There are "many different and valid ways" to do OAuth2 but I would recommend using cryptographic signatures on the tokens. Then your resource servers can validate the token without reaching out to anything else. Revocation may be a concern however. I gather that initially the token specification was vendor specific but that there is now a standard around this.

As far as username recovery and password resetting goes, I would not consider that part of the authentication service. I would separate that out into it's own process and set of services that is independent of the authentication service.