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