How to interact with back-end after successful auth with OAuth on front-end?

Question

I want to build small application. There will be some users. I don't want to make my own user system. I want to integrate my application with oauth/oauth2.0.

There is no problem in integration of my front-end application and oauth 2.0. There are so many helpful articles, how to do this, even on stackoverflow.com. For example this post is very helpful.

But. What should I do after successful authorization on front-end? Of course, I can just have flag on client, which says "okay, mate, user is authenticated", but how I should interact with my backend now? I can not just make some requests. Back-end - some application, which provides API functions. EVERYONE can access this api.

So, I need some auth system anyway between my FE and BE. How this system should work?

ps I have some problems with English and may be I can not just correctly 'ask google' about it. Can you provide correct question, please :) or at least give some articles about my question.

UPD

I am looking for concept. I don't want to find some solution for my current problem. I don't think it is matters which FE and BE I use (anyway I will provide information about it below)

FE and BE will use JSON for communication. FE will make requests, BE will send JSON responses. My application will have this structure (probably):

• Frontend - probably AngularJS
• Backend - probably Laravel (laravel will implement logic, also there is database in structure)

Maybe "service provider" like google.com, vk.com, twitter.com etc remembers state of user? And after successful auth on FE, I can just ask about user state from BE?

Answer 1

We have 3 main security concerns when creating an API.

1. Authentication: An identify provider like Google is only a partial solution. Because you don't want to prompt the user to login / confirm their identity for each API request, you must implement authentication for subsequent requests yourself. You must store, accessible to backend:

   1. A user's ID. (taken from the identity provider, for example: email)
   2. A user token. (A temporary token that you generate, and can verify from the API code)

2. Authorization: Your backend must implement rules based on the user ID (that's your own business).

3. Transport security: HTTPS and expiring cookies are secure and not replayable by others. (HTTPS is encrypting traffic, so defeats man-in-the-middle attacks, and expiring cookies defeats replay attacks later in time)

So your API / backend has a lookup table of emails to random strings. Now, you don't have to expose the user's ID. The token is meaningless and temporary.

Here's how the flow works, in this system:

User-Agent    IdentityProvider (Google/Twitter)   Front-End    Back-End  |-----------------"https://your.app.com"---------->|                                                     |---cookies-->|                                  your backend knows the user or not.                                        if backend recognizes cookie,                            user is authenticated and can use your API 

ELSE:

                                             if the user is unknown:                                                     |<--"unknown"-|                      |<----"your/login.js"----------+                 "Do you Authorize this app?"  |<------------------+  |--------"yes"----->|                      +----------auth token--------->|                      |<---------/your/moreinfo.js---|                      |-------access_token ---------->|                 1. verify access token                 2. save new user info, or update existing user                 3. generate expiring, random string as your own API token                                                     +----------->|  |<-------------- set cookie: your API token --------------------| 

NOW, the user can directly use your API:

 |--------------- some API request, with cookie ---------------->|  |<-------------- some reply, depends on your logic, rules ------| 

EDIT

Based on discussion - adding that the backend can authenticate a user by verifying the access token with the identity provider:

For example, Google exposes this endpoint to check a token XYZ123:

https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123 

Answer 2

I read through all the answers very carefully, and more than half the people who responded are missing the question completely. OP is asking for the INITIAL connection between FE & BE, after the OAuth token has been issued by the Service Provider.

How does your backend know that the OAuth token is valid? Well keep in mind that your BE can send a request to the Service Provider & confirm the validity of the OAuth token, which was first received by your FE. This OAuth key can be decrypted by the Service Provider only because only they have the secret key. Once they decrypt the key, they usually will respond with information such as username, email and such.

In summary:

Your FE receives OAuth token from Service Provider after user gives authorization. FE passes OAuth token to BE. BE sends OAuth token to Service Provider to validate the OAuth token. Service Provider responds to BE with username/email information. You can then use the username/email to create an account.

Then after your BE creates the account, your BE should generate its own implementation of an OAuth token. Then you send your FE this OAuth token, and on every request, your FE would send this token in the header to your BE. Since only your BE has the secret key to validate this token, your application will be very safe. You could even refresh your BE's OAuth token on every request, giving your FE a new key each time. In case someone steals the OAuth token from your FE, that token would be quickly invalidated, since your BE would have already created a new OAuth token for your FE.

There's more info on how your BE can validate the OAuth token. How to validate an OAuth 2.0 access token for a resource server?