4

I am starting a new web project and I intend to make it API based; that is I want to build the API first, authenticated via OAuth, then build a website and possibly mobile app(s) that use the API to handle data. I also have my eye on opening up the API to the public.

Here is my issue; I am struggling to get my head around how to authenticate these 'official' apps, the ones made by me, including the main site.

In OAuth the client creates an account for each user then seeks access rights via the resource owner logging in at the main site. This obviously does not work for me because the main site and the client are the same place and it also implies my users should be creating two accounts just to use my website...

I believe twitter uses its own API to run twitter.com and I get the impression that this approach is becoming quite normal so there must be a standard approach.

I must be missing something, but what?

Improve this question

2 Answers 2

Reset to default
5

You are confusing the API (business logic) with the authenticaton of user identity (for example logging in), and the authorization of third party apps (OAuth).

It is correct that twitter.com uses their own API. But they don't use OAuth on their own site. When you're on twitter.com, their APIs are available to themselves over cookie authentication. To put it simply: you're logged in.

Once you move away from twitter.com you have to use OAuth. Now an application is using the API on behalf of a user.

To sum up. You don't specifically need OAuth for your "own" web client to use your own APIs. You need OAuth, or some other authorization mechanism, to publish your APIs and it will also come in handy for your own "official" apps.

There is really no need to distinguish your own official apps from third party apps. Not from a technological perspective anyway.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Ok great, that makes a lot of sense. It seems pretty obvious now but I needed it spelling out. Cheers
1

Host two versions of the "API". One mapped to the external domain api.yoursite.com and it OAuth-enabled to authenticate all requests. The other internal version is accessible only within your pool of servers, your official apps. Since only your official apps can access it in the first place, consider all requests to the internal API trusted.

If you want the same application to manage both external and internal calls, you can choose to

  1. distinguish external and internal requests based on incoming IP addresses
  2. implement your API to accept one of "VIP passes" or OAuth tokens for authentications. External apps use OAuth tokens to perform actions on behalf of certain users. Official apps use "VIP passes" to perform actions on behalf of any user.
Improve this answer

1 Comment

Cheers but it seems like there is no reason to host two separate versions but rather have two ways to authenticate like in the accepted answer.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.