Stackexchange API Implicit vs Explicit

Question

This question is inspired by the documentation on the stackexchange and facebook API (http://api.stackexchange.com/docs/authentication) but is probably more widely applicable to OAUTH 2.0 in general.

My question is, why would you want to use the explicit authentication model when the implicit model seems like much simpler why of authenticating and getting access to content?

Are there limitations implied by the implicit approach and which is the most suitable method for a node.js application which is technically a server side app but which seems like would be suited to the use of the client side javascript libs.

Edit

After doing some reading it appears the "implicit" nature of the web client flow stems from the fact that the Resource Owner (user), implicitly trusts the client (the web browser). This means the simplified flow is appropriate, given this implied trust is a given.

This still leads to the question that when performing authentication via OAUTH 2.0 that the Resource Owner (user) must be vigilant as to whether they implicitly trust the client or not. This seems like a potentially dangerous stance as it assumes awareness AND knowledge on behalf of the user and there seems likely to lead to security concerns.

Gavan

Answer 1

Talking of OAuth 2.0 and not stackexchange API's specifically, there is an element of risk in the implicit flow, also called the implicit grant flow. This is because the authorization server sends the access token to your user agent/web browser.

To minimize any damage that could result from this, the access tokens were made short lived. Also, an access token, in this scenario, can be used only for the scopes that the user provided authorization for. This type of flow is mainly used for simpler web apps, that do not have a server to support them. The rather irritating apps that you see on Facebook could be an example, every other developer can use this implicit flow without having to worry about arranging for a server.

The explicit flow, called the Authorization code flow is far more secure. This involves the user agent receiving an authorization code from the server. This code can only be used by the app that registered - the server that you would maintain at the back end, with valid credentials.

An example :-
Let's assume there is some Google app that uses Facebook graph APIs. You can open the google app website and authorize
i) Either the browser receives token, the webpage made by the google app ensures that it hits the APIs, fetches the data and returns it to the server.
ii) OR, the browser gets a token and the webpage returns it to the google server. This ensures that only Google can hit the Facebook API (a sense of relief for a big company). Also, there is a central server that manages all requests and can easily generate any sort of metrics for monitoring requests/numbers/patterns.

One more major use of this explicit flow is offline access. In the above scenario, your app server can fetch a Refresh token and can call the REST APIs even when you are not logged in.

If you do have a server side app, I personally would recommend using the authorization code flow /explicit flow.

Simulation

Thanks for the answer. It goes a long way to answering. I understand the implementation differences between the two flows and the additional security plus ability to make off line requests using access tokens that do not expire seems like a good reason to use explicit flow when possible. It seems like the expiry of the token is down to the authorization server and not, which seems more correct, the user. For example, stackoverflow allows no-expiry tokens from implicit flow. This means that it's easy for clients to use implicit flow for long sessions without the explicit consent of the user. – Gavan

expiry of the token is controlled by the server, and never by the user in any OAuth implementation. Apologies, but I might not have understood the question. Is there anything specific that you wanted to ask? Because it does seem that you questioned yourself and answered yourself. (I do that a lot!) Try being more specific with the requirement, it might help you and me some others too!! :) – Simulation