Sharikov Vladislav Sharikov Vladislav - 2 months ago 6x
AngularJS Question

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

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 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.


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,, etc remembers state of user? And after successful auth on FE, I can just ask about user state from BE?


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
                                 your backend knows the user or not.
                                       if backend recognizes cookie, 
                          user is authenticated and can use your API


                                             if the user is unknown:
                "Do you Authorize this app?"
                     +----------auth token--------->|
                     |-------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 ------|


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: