An API of this nature allow us to develop native apps for use the forums (or just do a simplefied web UI interace and compile it using phonegap ), and easy interact with other software (CMS, or custom webpages).
About authentification, i like the twitter o github system, u create a key in your UCP and u use that key for auth external apps to connect to the forum.

naderman wrote:It does seem like most APIs of big services are switching to oauth for authentication. I think it's important to keep in mind what kind of uses the API will see. I can see it used by custom code by the owner of a site in which case something simple is nice. But I can also see it being used by mobile apps for example, in which case oauth would be the better option. So maybe having either depending on what the goal is may be the best option?

Nowadays OAuth is the industry standard and I really think that our REST api should be implemented on top of OAuth2.
This involves, in a first step, to have an api where each app has to be registered on each forum but I'm fine with that. Later we could try to find a way to allow "global clients" (in the OAuth standard, the application is the Client), ie. a client which doesn't need to be registered on each forum but the point require some work and we have to answer to a few questions but for me the priority isn't very high and it should be discussed in an other topic.

So to sum-up: I prefer to have a strong and complete api implemented on top of OAuth2 (with multiples authorization grants, scopes, multiple access token types...)

I've thought for a while about what you have said and what we discussed, and I'm still unsure.

My vision of the API was a generic type of an API. A developer could write a single application, say an Android app, which can then be used with all boards (provided that the board has the API turned on and the user has permission to use it). In this case it would not be possible to register an application on every board, unless the user that is using the application register the application themselves (doesn't that go against the point). How many phpBB boards are out there? I don't think a developer wants to register with all of them. A centralized solution might be an idea, but I think it has a lot of downsides as well. To create specific applications for each board would probably not be possible. Only the biggest boards would probably consider creating an application using the API, and I'm unsure why they wouldn't just make a custom solution anyway in that case.

However, I could see a dual-auth system. Some board owners may want an API that can be used with any application, some owners may only want to allow registered applications and some may only want to allow their own applications. We could leave it to the board owner to select what's apropriate, using the current auth system for those boards that want to allow all applications, and an OAuth2 solutions for those who want registered applications/own applications. And we could look into a centralized repo like we were discussing in IRC.

But to be honest, I'm not very knowledgeable about OAuth2. Maybe there is a way to implement it without having the application to register everywhere, but from my understanding you do need both an application key and an user key.

I stumbled upon something called JSON Web Tokens on reddit earlier this week. This blog post mentions OAuth2 compliance as well as self-issuing tokens without a central issuer. http://jwt.io/. I haven't looked at it very much and I dunno how it can be used or if it even does anything that we want to do (had a busy week so I couldn't look into it very much) but it seems like they also use a HMAC SHA256 solution, with scopes added.

The blog post you link is talking about their proprietary and not free solution (using a central repo) and they don't give any details.

But that's not the point here. I think that finding a way to have a global application should be an other discussion and shouldn't impact the development of the API. For that the solution we found will be an extension OAuth2 as planned in the OAuth2 RFC (ie. a custom Authorization Request, maybe using JWT but that's for an other discussion).

We are currently developing an API extension! It's undecided as to whether or not it will be open sourced. It supports JSON only and provides hooks where needed such that extensions can alter the data (ie. the Trader extension can add user specific stats to the users objects).