Questions About Consuming Your Own API with OAuth

Question

I'm building a RESTful API for a project I'm working on and I'd like to make the main application consume the API because:

1. It will result in having one set of code to maintain
2. Should we decide to expose the API for 3rd party devs it will already be done
3. It opens up the possibility to make mobile applications that consume it
4. I really want to learn how to do it

The API will be hosted on a subdomain https://api.example.com and the main web application will be hosted at the root domain https://example.com.

Conceptually I understand how everything works, but my main question is how the authentication flow will change if, at all. Ordinarily 3rd party apps would:

1. Obtain a request token from https://api.example.com/request_token
2. Redirect the user to authenticate on https://api.authenticate.com/authorize
3. Get redirected back to the 3rd party application
4. Obtain an access token from https://api.example.com/access_token

Since I control both domains, can I do something similar to:

1. Obtain a request token when the user lands on the login screen at https://www.example.com
2. The user authenticates using a form on https://www.example.com that calls the same code as https://api.example.com/authorize
3. If the credentials are valid, the request token is swapped for the access token
4. Access token is saved in the session and expires when the user logs out like it normally would

Step 3 feels like it's wrong since there will be duplicate code, but wouldn't it open me up to XSS attacks is the login form on https://www.example.com sent the data to https://api.example.com since they are technically different domains?

Am I overcomplicating this?

Answer 1

I have come across the same issue and solved it like this.

1 For third party apps, using my API, they have to authenticate via OAuth on all requests.

2 For my own third party clients, (mobile, AIR etc) - they use OAuth, with the difference that I allow these to send username and password directly in the authorization step (so I can make a native login dialogue). This is provided that your API is over SSL/HTTPS.

3 For my web application, I use cookie authentication to access the APIs. I.e after having logged in, the user could simply call API:urls and get JSON/XML back. Nice for quick exploring the APIs also (although a real API Console like APIGee does a better job there).

Answer 2

I would say you're overcomplicating it a little. If your code is seperated properly, you can easily build a thin REST layer over your application's service layer, while having your application's controllers be a thin layer over your service layer as well.