Secure OAuth in Javascript

Question

I have an api which uses OAuth 1.0a to authenticate applications using it. It\'s replacing an old api which used a number of custom built and hodge-podge calls which are being d

Answer 1

Just a few thoughts for those coming to this post afterwards:

1. "Is this secure" -> it depends on which threats we want to protect from. I will assume in the following points that the solution already implies a trusted network link (to prevent in-transit token or credentials interception attempts). However, a crucial element is missing in the description as it doesn't mention whether we protect the API from unauthorized users (human beings) or from unauthorized API clients (like a rogue extension running within the browser). The former can be achieved quite easily with available open standards, whereas one should forget attempting to prevent access from unauthorized extensions as the model fundamentally relies on an open-source client-side technology. This relates to workstation security more than designing a robust authentication/authorization mechanism. We can still implement some sort of extension authentication mechanism but it will be useless against someone who knows how to read extensions source code.

2. There are basically two ways we can design the platform. Either by instrumenting the API to allow querying the authentication service. Or using token-based access, in which the API will request the presence of a valid token in every request it receives without being its emitter. This would mean extending the authentication service with a new role: API ticket issuer, which is rarely interesting. When reading the proposition, it seems we are merging both worlds by forwarding the session token to the API. This is wrong. First, this is not why the cookie-based session token was designed for. Second, it forces the API into implementing some sort of real-time synchronous link with the session management system of the user authentication service -> coupling that we can avoid easily.

3. I will assume the main objective is to protect the API from unauthorized users and that we will not try to address threats relying on local system access.

4. Now, considering we will not implement authentication logic in the API, we must rely on a model where users authenticate to the authentication service, thus enabling any underlying extensions to request an access token.

5. This modifies the original scenario as follows:

   • The user logs into the website with the browser.
   • The website issues a cookie containing a session key.
   • The extension can now send a ticket request to the authentication service. Requests will include the session token (default browser behavior) and will therefore be authenticated.
   • Once the extension receives the ticket, the extension forwards it to the API and requests a session token.
   • The API validates the ticket by interrogating the session manager. If the session manager says "yes, I made this ticket and it is still valid", the API generates a session token and returns it to the extension. This token will inserted in all the subsequent requests, not the ticket. This will avoid any unnecessary workload on the session manager.
   • The token (do not confuse it with the ticket) can have a very short lifetime such as a few minutes -> if it expires, the extension just returns to the authentication service and asks for a new ticket (return to step 3 above).

6. The above solution basically relies on how secure both the ticket and the token are. Their design must at least implement countermeasures against the following 5 remaining threats: i) attempts to guess the ticket/token (secure-enough random generation), ii) attempts to compute the ticket/token (large-enough entropy), iii) attempts to reuse the ticket/token (expiry), iv) attempts to tamper a valid ticket/token (integrity checking), v) attempts to access the API without a valid token/ticket (validating the token in each and every request the API receives).

7. One additional advantage of this approach is that we can optimize resource allocation by emitting extension specific tokens, which in turn will trigger specific logic on the API (reduced API access, reduced lifetime, request throttling, etc..)

Hope it helps.