brunoais wrote:Ups. Wrong word. I meant, an extension to be listed in phpBB's extension list.

No, the word was OK, just the parsing was ambiguous. You meant the official list of extensions, not the list of official extensions. I parsed your original as you intended, but can see how others might not have.

with OAuth2 you can define many way to provide a token, and you even can add a custom one. And we could imagine a custom provider with a private key set displayed on the acp and which could be deactivated. We could also have a pubic api (corresponding to what a guest can see).

But anyway don't forget one thing: if you want to act as the user, you need to be authorized for and that's the point of OAuth: to give you the authorization to act as the user without having to know his password and his login, you just need a valid token.

Note: well, what I said in the first part can be a little confuse, so to sum-up: if you can trust your application you can implement a custom token provider but you still need a way to identify the user from your application (and in this case, if you can trust the application, you could request the user login and password yourself and provide it to the board in your OAuth request, but for obvious security reasons this request should be encrypted by a private key shared only by your application and the board and because you need to embed a private key it's not suitable for a client base application)

I agree and it can be done with a custom token provider (I don't remember the exact name) in OAuth2. So in the first time I think that the most important is to support the most common: An open API for users (with user authentication). In a second step we will add the ability to access some resources as guest and finally the custom token for a trusted app added manually by the admin.

But I really think it's easier and better to start with a limited api implementing the most common use case before starting to do something less usual and more complicated.

To start, I'm sorry I haven't actively replied for a while, I used to get emails whenever there was a new reply and for some reason I haven't got any mails in a long time so I assumed no one had said anything new (maybe I forgot to mark my last notification as read, and therefore wouldn't get new mails?)

Anyhow, seems like we have some different definitions and thoughts about an API, which have made me a bit confused. If I understand correctly, what @MunchWX wants is an userless API that is private to the board owner, meaning it could interact with phpBB in various ways without being connected to a user, am I right? Say, access to various board features that doesn't need to be in a context of a user (notifications of new posts, moderation, auto-post under a "non-user" account). I'm a bit tired right now and can't think of such an API on the top of my head, maybe something like the Android API where your app can use features of the OS.

That isn't the kind of API I had in mind at all. The API I had in mind was a "User" API, or REST API. Much like how Twitter and Facebook have APIs that allows developers to create apps which can post to Twitter/Facebook on the behalf of the user, like Tweetdeck or Falcon or any other application that can post on Twitter or Facebook under a certain user.

My vision was to let developers create apps that can make use of any forum (and not only a single one at a time, but ability to add multiple forums to the app) where the API is enabled.

Maybe I have been unclear, or maybe I'm the one that's confused, but I thought it would be good to try to define what we want to do.

Regarding the authorization/authentication, it's a hard choice. OAuth2 seems widely used but for some reason I have a really hard time understanding it. I've tried a couple of times and it seems simple enough but then there is some catch or something new and complicated, and I feel like I can't really make a choice without fully understanding what you can do with OAuth2 and how you use the different strategies.

Both auth systems proposed, mine and OAuth2, have their advantages and disadvantages, but maybe the disadvantage of OAuth2 can be worked around if you actually know how each strategy works.

My understanding of OAuth2, as previously discussed, is that the forum needs to know about each app, the app developer has to register their app with each forum the app is used on. This works nice when there is a single service, like Facebook or Twitter, but not so much for where several services (forums) share the same API.

I know we have discussed this before in IRC. It wouldn't be feasible to have an app creator register their app on every phpBB board (how many are there?) since that would take lots of time, and imagine managing hundreds of application keys in your app that you are distributing to your users. The developer might even give the user the responsibility of registering the app on each forum they want to use, but doesn't that defeat the purpose?

A centralized solutions was discussed where app authors would register their apps at phpbb.com, but that's probably not what we want. It would add a large cost and would it go down then the API would stop working completely. Not to mention all the app keys would have to be distributed to each and every board (and I dunno, but the app keys in OAuth2 should be secret, right? With a centralized solution, they can't be secret).

OAuth2 would work fine if forum apps were made specifically for a single forum, but that wasn't my vision from the start when I proposed the API.

My auth system makes it possible to use any app on any board with the API enabled, but obviously it needs work and has it's disadvantages. For example board authors can't control which applications can access the board, and it's a custom-made solution and not very well-tested.

What @MunchWX wanted to do could possibly be implemented in the current API in the future, where you could maybe generate some special keys in the ACP which would allow your app to access the API without having to be connected to a user.

I was thinking a bit about how to approach this. Maybe we could implement both and let the board admin decide what kind of API they want, a board-specific OAuth2 API, or a board-neutral API, or both and give different permissions based on API type. What do you think about that solution? IMO it is up to the board author to decide if they want to open up their board API to everything or just specific apps.

Actually I think that we can do everything with OAuth2 and that's why I think we should start by implementing it in its more common way. Then we will be able to enable (or implement) more ways to obtain a valid token.

Because the most important thing about OAuth2 is that it retrieve a token and then it uses it for every request but how does the application get a token it's up to us (the protocol have some way already defined but we can add as many as we want)

I will apologize in advance, because I don't have the time to read this entire topic.

When it comes to authenticating API's it is less about how the authentication is done, as long as it is token based. If the token is compromised (even if it expires and is refreshed periodically) it is pretty close having access to a plain text password while it is valid.

So, unless you use something like public key authentication, which obviously overkill is by far the most secure option (https everywhere sounds nice, but that is all it is) it is more about how to limit the potential damage in the event of a token being compromised, because that is just a matter of time.

The best choice is an observer only API of course (while information leakage is still an issue here, data loss is not a risk), however, if data modification is a must the best options are an API that does not allow data removal or is sandboxed as such that the only data that the API can modify or delete is data that was authored by the API using the currently valid authentication.

Crise wrote:
The best choice is an observer only API of course (while information leakage is still an issue here, data loss is not a risk), however, if data modification is a must the best options are an API that does not allow data removal or is sandboxed as such that the only data that the API can modify or delete is data that was authored by the API using the currently valid authentication.

I actually thought of having different scopes the user could select, where a read-only option would be an option, OAuth 2 should be able to support that from what I've seen.

Regarding data modification, it's a complicated issue. If the user authorizes an application, who knows what it will do? The user needs to trust the application, and even if the application comes from a trusted source, there's always the risk it could be compromised in one way or another (see puush).

Currently, in the old pull request, every post submitted via the API get an API flag for moderators and admins to see (I don't remember though if I made it to indicate which API key posted the post). If an API would start posting spam, it's inconvenient but easily revertable, just remove the API key and all posts made by that API key (provided all posts were spam).

If however the application wants to be evil and just automatically remove/edit all your posts, it's difficult, since it's hard to recover from. You obviously want to be able to post, edit and delete from the API, but there needs to be some kind of safety. Putting on a limit of data modification calls could work, but only prolong the process (so instead of deleting all your posts within seconds, it could take a longer time to delete your posts depending on amount of posts you have). Maybe do the delete call a "soft delete", which marks the post for deletion. In the view of users the posts are deleted, but they actually get deleted after a period of time. That way someone, either the user or other users would notice that the user is missing posts, and the user could restore them.

If it's just "subtle malicious", removing a random post once in a while, it would be hard to catch. We could have a history log of API calls, but that would obviously require the user to check the log.

I think we can do a lot of things:
- clearly separate the scopes (READ_PUBLIC, READ_PRIVATE, WRITE_PUBLIC, WRITE_PRIVATE, MODERATION_RIGHT, ADMIN_RIGHT etc... we can imagine what we want)
- flag the posts, messages etc...
- use quotas
- force soft delete for the API
- ...

Just something I was briefly thinking about regarding API authentication, I thought I might as well write it down here.

What I would do is employ a TOTP approach for the tokens, that way the actual token for each request is unique and only ever used once and the tokens will be near impossible to be compromised unless the actual pairing process is being caught over the wire. I am not overly familiar with OAuth2 specifically, but as I understand it the spec doesn't guarantee anything besides that communication should be https (as in it leaves, in my opinion, too many choices for the individual implementations).

Seems to me that this is at least a better choice than a refresh token, which seems to be the common way for changing the actual access token to a new one (aside from full re-authorization). It would also allow a scenario without https to remain reasonably secure and functional if necessary.

My own preference for API's is always making the remote implementation as simple as possible to be honest, which means avoid authentication whenever possible and if the trust level permits it use an API key assigned and/or revoked by the administrator (and only by the administrator). I wouldn't use this for an open system though (ie. one where "unprivileged" users are meant to be able to readily hook into the API or were the servers conditions may vary), same reason I avoid remember me cookies in my own apps, because there is no real guarantee the data in that won't be misplaced by some stupid browser out there.

I would vote for adding OAuth2. The implementation should included the openid connect functionality. This would allow the phpBB login and registration system to be utilized by other web applications. Most other common web applications have a oauth login ability. This would allow for easier integration between web applications.