Authentication when separating API from web application - php

Question

I am currently planning the restructuring of a web application to separate the API from the application. Right now, users log in to the application by entering their operator ID (username) and password into a standard HTML form and the authentication is done by checking the database table and creating a PHP session (handled using Zend_Session). I'm not sure how to continue doing this after separating the API.
Here is some simplified code to illustrate how things currently work:
// GET https://foo.example.com/module/trips.php
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
require 'views/trips.php';
}
// POST https://foo.example.com/module/trips.php?action=take
// ...
// this request can come from AJAX, for example
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
$model->assignTrip($SESSION->operatorID, $_POST['trip_id']);
}
Obviously this isn't very RESTful, hence the effort to separate the two. This is what I proposed (still a work in progress):
// GET https://api.foo.example.com/v1.0/trips
echo json_encode($model->getAllTrips());
// POST https://api.foo.example.com/v1.0/trips/:trip_id/operator
$model->assignTrip($_POST['operator_id'], $trip_id);
I understand that REST is stateless. In this simplified example, only the operator should be able to assign himself/herself a trip. How do I enforce this with the API?
I've read many, many questions and articles about authentication with REST APIs and they all talk about OAuth/OAuth2 which seems great for authenticating clients of the API via tokens but nothing about authenticating users of the API client (or perhaps I'm misunderstanding something?) In my case, my API client is still the web application.
My main question: How is the API supposed to determine who the user is? Or is it even supposed to?
Alternatively I have considered doing this in the web application:
// POST https://foo.example.com/module/trips.php?action=take
// ...
// this request can come from AJAX, for example
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
// Use cURL to send an HTTP POST request with the appropriate data to
// https://api.foo.example.com/v1.0/trips/6/operator
}
That seems like unnecessary overhead but that's what it looks like in this answer. I thought that after my restructuring I should be doing something like this from the JavaScript:
$.ajax({
type: 'POST',
url: 'https://api.foo.example.com/v1.0/trips/' + trip + '/operator',
data: {
operator_id: 6601
}
}).success(function() {
// It worked!
});
I've looked at GitHub API Authentication as an example and the Basic Usage uses curl -u "username" <api-endpoint-url>. I'm not concerned about using the Authorization HTTP header as this application is already HTTPS only but in this case wouldn't I need to store the password in the locally (e.g. Web Storage or something)?
I've also read this blog post and I'm not sure if that's what I'm supposed to be doing and if so, am I supposed to include the username and password in that hashed blob of data?
Perhaps I am misunderstanding how APIs are supposed to work in general, if so it would be great for someone to clear that up!

Answer 1

I agree that send some header data and store it localy are strange, but, believe, that's the way.
You can take a look to HMAC authentication.
A lot of APIs today use it, or adapt it to work with. You will ever send some user ID in header, concatenated with your hash. The server will recognize the user by that readers.
You don't need to store the password localy, just the hash (or a token) sent by server when the auth request are made.
Clearing all:
Make the API call to authenticate the user
The server will check the user login/password, if all fine it will store a TOKEN and return it on the request.
The client store the token
All the subsequent request will send that token in the header
The server will always check if that token are valid, and, find the current user using the token or another data sent in headers