I've been reading a lot lately about Web API authentication mechanisms and I'm a little bit confused regarding how to implement my Web API authentication mechanism, I'm thinking on using Token based authentication but I'm not sure if it is the right choice.

Basically my Web API will manage all the operations needed and it will store the users of my website as well the API users.

I want to support the following

  • User can register on my website and apps using their G+ or Facebook account or an already created username from my service, as well they will be to login using their social account.
  • If the user is not logged in they won't be able to post Items but they will be able to see the Items, think something like Craiglist.
  • Let's say the user is a developer and they want to post the items through some software they created instead of going through the website and posting one item at a time, how do I allow this?

Now, my questions are:

  1. When a user registers on my website, do I have to create a (public key/ secret key) for it subsequent access token , so I can use my API from the website as the user checking if they have access to certain endpoints?

  2. Do I have to assign a (public key / secret key) for my website so I can consume the API when the user is not logged in?

  3. The same as above for mobile apps

  4. How do I allow users to (sign up / sign in) using G+ or Facebook?, if they log in using any social network how am I going to secure my api?

  • Why do you want to allow apps to have special privs? Can't you force the apps to use an authenticated user? Commented Feb 26, 2016 at 3:39
  • I don't . I just want to know what is the best way. What's posted is why I'm considering right now for the lack of better solutions. I want the app to be able the retrieve all items even if there isn't an authenticated user so I thought this is a some kind of special privilege. Commented Feb 26, 2016 at 4:17
  • 1
    OpenID connect is the answer for Question 4. I hope someone answers the rest!
    – JOW
    Commented Feb 26, 2016 at 14:26

1 Answer 1


You need to separate authentication and authorization.

Authentication ensures that your web site knows that the incoming user is actually the one you have on file. In other words, once someone has registered as bob in your application, everyone claming that he is bob is checkd via authentication.

As you mention, you have several choices for authentication. You can offload the process on some well-known identity providers (Google, Facebook, LinkedIn, ...). They will make sure that someone coming in as Barack Obama has been authenticated as such on their side.

It is important to understand that you do not know whether Barack Obama logging to your site is indeed the US president. The only thing you know that someone registered as such on, say, Google and the same person will be consistently authenticated as such via Google.

You need to look up the identity management on the various sites you want to use (Google for instance). The keywords are OAuth and OpenID.

Now that you know that Barack Obama is coming in, you need to give him or her access to some things and not to others. This is the authorization part. It is completely dependent on your application.

What you will be basically coding is that a specific ID (which is ultimately the user logging in) can see some content. OWASP will help you to make it secure.

An advice: if you can completely offload authentication to someone you trust and your users will trust (typically the big players above), do it. Do not be Adobe.

  • thanks for clearing that out, I'm pretty new to OAuth and API design so that really helps, can you tell me then if the process would be something like this: 1) User registers on my site using some identity provider, I save their email to compare against my db . 2) User logs in using the identity provider 3) I check if I have that user in my db using their email 4) If successful then I just check for authorization I have seen other site like Stack overflow that also allows to create an account on their site, does this means that they also implemented their own authentication system? Commented Feb 29, 2016 at 4:01
  • 1
    For 1-3: yes, you would basically challenge the user though the service provider, or to have for some time an authorization token (which you will check with the service provider). I recommend to read the Google docs on their authentication, they are comprehensive and relatively understandable (three-legged oAuth is not obvious).
    – WoJ
    Commented Feb 29, 2016 at 14:48
  • 1
    As for 4: if you have a site which requests a login and a password then it stores it somehow. The idea is that some people could prefer to create an account instaed of using Google (as they may not understand the implications - which are positive for them). This carries great risk, you must absolutely store it correctly (see for instance dustwell.com/how-to-handle-passwords-bcrypt.html, except for the recommendation about choosing a password passwords which is not correct, but it does not matter in your case)
    – WoJ
    Commented Feb 29, 2016 at 14:48

You must log in to answer this question.

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