2

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). enter image description here 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.

  • Why C is stateful? If there's any. Should not be at B? C and D will check (so far) if the token has expired (that's what you call session). – Laiv Dec 10 '16 at 19:39
  • C have to be stateful, it contains the business logic. and when I say "session" I mean a coockie stored in the browser, not the OAuth token (or any other auth token) – RikyTres Dec 12 '16 at 7:38
  • @Laiv, we are considering to fuse C and B in a single server. We don't find other solutions and anyway sounds more correct by the architectural side. – RikyTres Dec 14 '16 at 8:17
  • 1
    To have separated the MVC from the business the way you were doing is fine. You are being affected by a technical issue, it's not by a design issue. From my point of view, C should be stateless. B ask for a token to D (because the client here is B) then pass the token to C and C just ask D if the token is valid. As soon as you solve the problem, the solution is right. Just think again why you wanted to keep MVC and the business decoupled and if by merging you are not accomplishing any important requirement. If you aren't, go ahead. – Laiv Dec 14 '16 at 8:41
  • also consider implementing an Api Gateway. this is an extensive subject. Google a bit by: Api Gateway and Api Management. – Laiv Dec 14 '16 at 8:47
9
+25

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.

One-Way SSL

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.

Two-Way SSL

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.

OAuth2 flux complete

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.

  • 2
    And don't forget to use https. You will need a digital cert. – Laiv Dec 8 '16 at 20:02
  • 1
    +1 for HTTPS @Laiv. Edited. – linuxunil Dec 9 '16 at 0:57
  • 1
    @RikyTres that would help. I think you already know the OAuth2 protocol, but what worry you is not exactly the protocol itself. Looks like you are looking for a plan to make your environment scalable. Allowing new APIs or ClientsApp to consume your services. Am I right? Is it about the architecture plan? – Laiv Dec 10 '16 at 18:30
  • 1
    Yep, you're right. I use OAuth to make scalable the AuthServer, and now i'm making a service that is a OAuth client. Now I need to make scalable also this service, and I create a server that expose a web GUI, and use the API of the OAuth client. – RikyTres Dec 10 '16 at 18:34
  • 1
    @linuxunil I think you should read the OP's edit and edit your answer too. You have introduced briefly concepts of web security and one of the possible flows for Oauth2, but questions turns around another subject. – Laiv Dec 10 '16 at 20:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.