I am designing a web-based back-end for an online service. The service could support web based portals and mobile apps as front end.

But I am stuck on how to support third-party, i.e untrusted, web sites as front end. In fact the same issue exists with mobile apps, though maybe to a lesser degree.

Briefly the issue is that authentication and authorization should happen at the back-end, and the question is how to ensure that a middle-tier or web portal does not save a user's secret credentials or through some other means can pose as an end user and perform operations that the user is not requesting!

I need to be able to authenticate the end user at the back end and I've currently got a working proof-of-concept, and the registration and authentication processes for this are as follow:

  1. New user connect to public registration page.
  2. Maybe Include JS to generate a public/private key pair?
  3. Authorize access to Oauth provider for basic profile info.
  4. Retrieve user details and populate profile.
  5. User supplies additional info (eg contact number, recovery email address) and their public key to complete the registration process.

And then the Authentication process for a returning user would be something like:

  1. User application (Android or Javascript) builds a JSON formatted request.
  2. Application signs request with user's private key.
  3. Application attaches user's Identification (user-id / open-id / etc) to the request.
  4. Application posts the request to the API (back-end).
  5. API checks that request is authenticated for the specified user (verifies signature)
  6. API checks that requests is authorized.
  7. API processes request and builds response.
  8. API encrypts response using user's public key.
  9. API attaches some basic information (eg API version and request-identifier) to the response.
  10. API returns the response in the user's HTTPS session.

As far as I can tell the problem comes in at step 4. The Application could submit the request to anywhere, eg a third party web site that adds benefits such as formatting and advanced functions. But this means the middle tier wil submit multiple queries to the back end on behalf of the end user, build the response, and return that page or report to the user.

By the way I am hoping to leverage two specific benefits from using openid / oauth (which I have not yet got working in my proof-of-concept implementation)

a. Make the registration process easy - user does not need to remember a new password and does not need to fill in all their details, just the bits the application need that is not supplied by Google+ and friends.

b. I do not need to deal with forgotten passwords / password resets in 99% of cases. As long as the user have access to their open-id account they can regain access to the service. When connecting from a new device, eg a second PC/tablet/whatever, the application creates a new public/private key pair and the openid provider party gives access to the user's profile. If the user switches to a new openid provider he can use the recovery email address to link a new openid URI to his profile on the system.

On the other hand I'm not looking to integrate with other more advanced features of the openid providers at this stage. I really just want a third party to handle the leg-work of identifying users and managing their passwords.

The problem is that the user registers with the back-end through an interface that may not be trusted. A bad middle tier may potentially substitute a user's public key for a public key that they control the private key for. How do I design for this kind of situation? Do I disallow third-party interfaces to the back-end completely (I would prefer not to be involved with the apps and web sites, though I will implement a reference application)

1 Answer 1


This is what oAuth is for. oAuth lets a third party service request to do certain operations on behalf of a user with the users consent, For example read access to a users contacts. The third party receives a token which allows it to perform these actions and it is the back end responsibility to validate the token and the actions it is allowed to perform. The token can be time limited and hence even if the third party keeps the token, it becomes useless after it has expired.

  • Somehow I had a feeling it would be about oAuth. Is my understanding correct that oAuth and oauth2 are two completely different things, that I need oauth2 for openid, and now as per your suggestion, oAuth for session authentication and authorization?
    – Johan
    Commented Jan 20, 2015 at 5:51
  • oAuth 1 was only about authorization and hence there was a need for a separate authentication mechanism such as openid. oAuth 2 incorporates both authentication and authorization. The newest version of openid (openid connect) is actually based on oAuth 2.0
    – aviv
    Commented Jan 20, 2015 at 12:28
  • I've started reading up about this topic, one that I've avoided for some or other reason for a long time, and yes you are absolutely right. Thank you.
    – Johan
    Commented Jan 21, 2015 at 6:03

You must log in to answer this question.

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