I have a back-end (API) and a front-end, eg a web server, and I have users and ID-providers.

The web server is provided by a third aprty and it may just as well be a mobile app, but whatever the case is, the user uses it to access their data.

Generally the users will need the Application (Web of Mobile) to be able to do everything for them because the API just gives out low-level responses in JSON format. So when a user requests that a front end be authorized, that gives that front-end full access to whatever the user can do.

The users register and authenticate by means of their Google/FB/Twitter etc accounts so that the API doesn't need to worry about passwords, and to make it easier for users to sign-up.

When the user views a resource, eg their messages or account history or profile on the back-end, they do this via a front-end.

The front-end then passes the request for the resource to the API (which is implemented in a REST-ish fashion). My understanding is that for this to work oAuth would be used to Authorize the web site to request the user's private information.

Please correct my understanding: After registration, the user logs in on the Front-end. The Front end then retrieves information for the user from the back-end via "oAuth Authorized HTTP requests", (oAuth 2.0 to be specific)

The Back-end sees that the request is authorized but doesn't know who was (presumably still is) logged in during this process? So how does the back-end know what mailbox or profile or transaction history to serve up?

The API will encode the specified mailbox or transaction history in the URI, but really the question is how does the backend know that the front-end is requesting the correct mailbox for the currently signed in user?


2 Answers 2


The oAuth sets a session token for every user. When the user is logged in to the front end the front ends send the token to the back end and not the username and password. Using this token the backend authenticates the user and show his profile. So using this token the back end recognizes the user and shows his profile on the front end. more info

  • Thank you for your answer, and I have not yet read your More info link. There is probably something really simple that I'm missing here. How can the Backend authenticate the user if he doesn't have the user's identity?
    – Johan
    Jan 22, 2015 at 12:49
  • When the user signs in to the front end, it uses an Identity Provider like Google or Facebook to authenticate. How does the BackEnd know what Identity provider was used? Does the oAuth provider talk to the identity provider?
    – Johan
    Jan 22, 2015 at 12:54
  • Yes it does provide the token
    – Irfan
    Jan 22, 2015 at 12:59
  • Do you have a reference?
    – Johan
    Jan 22, 2015 at 13:00

this question is similar to the one posted here: Login to one site using other site's credentials along with my answer.

But I will focus this answer on your specific concern. If I understand your question correctly, you are asking how your back-end can trust the data that is being given to it by the front-end. Essentially, you are thinking about it slightly wrong. When you initiate an OAuth transaction, the resource owner provides their credentials directly to the service (Google, for example). Some stuff happens then Google gives you back an access (bearer) token. That token is then used to get data from Google such as username or e-mail address. If you are using your front-end client to do an API request to Google for that information then you just simply put that data directly into your DOM. What you shouldn't be doing is requesting data from your front-end then taking that data and sending it to your back-end to bootstrap user information (or whatever), then yes that is a security and trust issue (So you wouldn't do that). The entire point of using OAuth is so that you don't have to rely on your back-end.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .