Guild Wars 2

Good news. Do we have full documentation with this API ?

How will users create an API key? Can they do this in-game?

Lawton Campbell.8517:

instead of registering an app and going through the OAuth2 code flow, users simply create and copy-paste an API key into your client.

I doubt that this would make anything better for the users. There are a lot of people out there who hardly know to start a pc and run their game – imagine these to create and use an API key. Despite of it’s flaws, OAuth2 is being used all over the web for way more sensitive applications and most users are used to it. I mean, we’re talking about an API account which reveals little sensitive data, not actual user account info (e.g. real names, address, billing info).
So the only thing you might mitigate is that a user gets their login data scammed (which also happens in so many different ways) at the cost of making the login flow less user friendly. You cannot mitigate PEBCAK.

I highly agree with smiley.

I still need to redirect my users to the official site. (Letting them create an API key.) The only relevant thing that changed is that there is no pingpack from official site and the rdirect is not officially included but necessary.

However i don’t think that it was a decision made by the programmer team. I think it’s better than nothing and i can deal with it …

smiley.1438:

Lawton Campbell.8517:

instead of registering an app and going through the OAuth2 code flow, users simply create and copy-paste an API key into your client.

I doubt that this would make anything better for the users. There are a lot of people out there who hardly know to start a pc and run their game – imagine these to create and use an API key. Despite of it’s flaws, OAuth2 is being used all over the web for way more sensitive applications and most users are used to it. I mean, we’re talking about an API account which reveals little sensitive data, not actual user account info (e.g. real names, address, billing info).
So the only thing you might mitigate is that a user gets their login data scammed (which also happens in so many different ways) at the cost of making the login flow less user friendly. You cannot mitigate PEBCAK.

This^

Also, English is not my native tongue but I have a very good grasp of it and the post of the Arenanet employee is barely even understandable to me.

1. His use of the language is incredibly complicated and
2. His explanation is highly technical

I would love him to re-explain what he means, just for us “common folk” who also play the game and completely do not get what he has just tried to tell me…

So do I understand right that the use of the Google Authenticator app is being stopped? Something else is going to be put in its place, but a decent guideline and description of where to do it would be nice, rather than me having to scour the internet for information.

Also a LOT of people do not read the forums. And definitely not the API development section. How are all those people going to be informed of this massive change?

Lawton Campbell.8517:

I don’t disagree. It is what it is. At the very least, this will make it more difficult since the expected flow doesn’t involve redirection from a third-party site to a login page.

I do disagree with the part about redirecting from a 3rd party site

The only user that will type in GuildWars2.com in their browsers, go to their account page manually and then create an API key instead of just pressing a button on the 3rd party site, are the users who are aware of phishing who wouldn’t fall for the OAuth phishing attempt either (because it is exactly the same)

A normal user will just press a button on the 3rd party site, leaving them just as vulnerable to phishing as before (it is the same).

We are also assuming that the sites that do want to steal account information do not just put in a button saying, “click here to ….” what ever that site might need and not a text saying “go to GuildWars2.com to retrieve your API key, see this tutorial for help on how to do it”

I fail to see how this new system changes any of the attack vectors

I’m going to jump in and say I agree with the others. This will do nothing to mitigate phishing, as most people will still link to the page. It will only serve as more of a hassle to the users for having to do extra steps, and developers who will have to provide extra support because this will confuse a lot of people.
This decision feels like it was made by some manager who read about oauth phishing on some business site, and decided he needed to do something to continue seeming relevant, even if he had no idea what he was talking about.

Firedancer.8350:

Also, English is not my native tongue but I have a very good grasp of it and the post of the Arenanet employee is barely even understandable to me.

1. His use of the language is incredibly complicated and
2. His explanation is highly technical

I would love him to re-explain what he means, just for us “common folk” who also play the game and completely do not get what he has just tried to tell me…

Hello, you have found the API development forum! This forum is intended for software developers who want to incorporate data from Guild Wars 2 into their applications. The content in this forum is not intended for the “common folk” who play the game.

Firedancer.8350:

So do I understand right that the use of the Google Authenticator app is being stopped?

Nope, this is completely unrelated to the two-factor authentication system for logging into the game. This post is about a method that users can leverage to provide a limited amount of account information to third-party apps, such as an Android app developed by a Guild Wars 2 fan.

Lawton Campbell.8517:

the change should make client implementation a bit easier — instead of registering an app and going through the OAuth2 code flow, users simply create and copy-paste an API key into your client.

If I’m reading this right, it sounds like authentication on mobile devices is going to be enough of a pain in the kitten that no GW2 mobile apps will have a smooth authentication path. If authentication is no longer a supported use-case, I’m struggling to see what use-cases are left where API keys tied to specific users are involved.

I’m not sure what the blocking issue is. I wonder if provisional keys might not be a good compromise – hand out initially non-working keys via the API that have to be approved by the user while securely logged in.

Previously we had a link “Click here to login with your Guild Wars 2 account”, now we have “Click here to login to your Guild Wars 2 account, create an API key with the permissions X, Y and Z and then come back here, paste it into that input and in case you did something wrong, do it all over again”.

It is only harder for the user, and every malicious site/app can still link to a fake login screen. I really don’t see how that is supposed to help with phishing. (Except for a few users saving their API keys in a password manager. But those few responsible users would probably want to generate new keys with specific permissions for every app, so they’d need to reauthenticate anyway. And they would probably not fall for phishing in the first place.)

TL;DR of the remaining post: Users are lazy, UX is horrible, doesn’t fix the phishing problem, OAuth was better for everyone.

OAuth was easy to implement (with thousands of tested libraries available for all languages/frameworks) and had great UX for users. API keys are horrible UX-wise. There are just so many scenarios that just don’t work well with API keys.

1.) Most Users will just generate 1 key with full permissions and reuse it for all apps. Once they want to revoke access to their account from one app (and the app doesn’t provide an easy way of doing that in the app/the user doesn’t trust the app to completely remove the key), the users has to generate a new key and reenter it in all other apps he uses. (There could be quite a few “passive” apps he doesn’t often visit and only notices the errors months after).

2.) An app requires the permissions X, Y and Z, but the users forgets that by the time he has logged in to the account page (can take quite some time: 2 factor, email for unknown IP, looking up password in password manager/phone/notebook, …) and only allows access to X and Y. Now the users has to do all that again after entering the API key in the app and getting an error. Maybe he was using private browsing and has to do the login to his account page all over again.

3.) An app requires new permissions after an update, the user now has to create a new key and enter it again, maybe even for multiple apps that required the same permissions before and he was sharing the key for.

4.) You create a new scope for the API, the user now also has to update all apps in case he only uses one key for all apps. And no matter how much we tell the users to generate new keys with specific permissions for each app, most users won’t do that because they are lazy and don’t see the problems of it in the future.

5.) Probably way more than that, those were just a few off the top of my head, but we will run into more problems once we are using them…

OAuth had easy solutions for most of these problems by simply doing most of it behind the scenes, leaving the user no way to mess up. Just clicking one button and the app had all required permissions with an easy way of updating/revoking permissions per app.

I know OAuth has some flaws, but API-Keys for users that don’t understand them are way worse IMHO.

First of all sorry for my non fluent english, I only want to say I disagree with most of negative opinion here so from the beginning. As a player and technics devices user (smartphones, tablets etc) You should be fine with browser interface and few simple inputs, so argument about not so smart players who barely can run their pc is kind of invalid IMO.

Second, with this changes (assuming that You are aware what are You doing) You have easy way to manage what app could read and there is no matter they’re not high risk data. It’s all about that little possibility.

At the end, I really looking forward for some simple url for generating keys for example

account.guildwars2.com/getKey/appName/base64_encode_rights with this kind of link user must loggin into account and they have simple message do you really want to create api key for application xxx with rights yyyy. After that system show key to user and from there is simple copy to clipboard paste into app.

There is no such things like anti-phishing mechanism because it’s not how it’s working You can be phished always and only secure mechanism here is your brain and eyes on url address.

This will actually make mobile apps better. Social logins are…problematic on those platforms, and requiring a 3rd-party server for APIs to work is a bit hacky depending on the use case.

I think it’s fair to say they won’t retroactively break apps with new scopes (or at least have no intention to), and if your app can’t handle switching based on available features…well, it should, because that’s always a user’s choice.

Lawton Campbell.8517:

Merus.9475:

If I’m reading this right, it sounds like authentication on mobile devices is going to be enough of a pain in the kitten that no GW2 mobile apps will have a smooth authentication path.

Yeah, the flow for web-based mobile apps is not going to be very clean, UX-wise. I’m probably going to put QR codes on the API key management page so that native apps can “copy-paste” the key into the application in a gross but somewhat feasible manner.

You can include all three scenarios:

• The raw number for copy/pasting
• A link with a URI scheme that apps can register for (guildwars2apikey://#key# or some such…maybe not quite that raw so it can be expanded later)
• A QR code with that same link

The raw number works for websites, the link works for native/mobile apps, and the QR code works for mobile apps from a computer screeen.

khesi.2786:

account.guildwars2.com/getKey/appName/base64_encode_rights with this kind of link user must loggin into account and they have simple message do you really want to create api key for application xxx with rights yyyy. After that system show key to user and from there is simple copy to clipboard paste into app.

How was this different from OAuth2 else than the part where the API key is transferred without the users interaction?

The user interface for managing token/api keys could be identical (they are basically the same)

What those of us who do not agree with the change mean is that the new API key system only brings negatives and really no positives as far as i can see

Those who are for the change, i would like if you could explain what the advantage is as all of the mentioned above are identical to OAuth2, only difference is the hassle it creates for the user

People are probably going to frown on me for saying this, but I actually like the possibility of having a single API key for more than one the services I use on my account.

Until every app can be granted meaningful separate privileges (the account api is the only authorized API we have right now, correct?) there is no real reason to have separate API keys for every application, other than malicious apps and possible per app throttling. However, the API really doesn’t nor should it ever allow much malicious behavior (and chances are by the time user realizes the app is malicious the damage would be done).

From developer point of view, this change has no real positives… assuming you are already conceptually familiar with OAuth2 and/or have a working implementation you can use. But for developers new to all of this it will lower the barrier to entry, which I think (correct me if wrong), is the goal here. This eliminates the need for writing or using “middleware” style code by being single API secret that is stateless in that it does not expire or have different types.

Lawton Campbell.8517:

Divine Don.9752:

How will users create an API key? Can they do this in-game?

Nah, it’ll be an interface on the account site.

We have an IT skill scale from 1 to 10 while ppl reading the API forum already get a 10 (we’re not talking about coders). In my opinion you need at least a 5 to handle this.

Let me describe this with a little story about a “3 points user”
1) A user starts an application (forum, mobile, voicechat)
2) The application may need its own authentication (e.g. forum login)
3) The user reads an explanation about “API” (what?) and “GuildWars2 Basic Account Information” (what again?)
4) A “direct” link is being provided. The URI points to the API-Key management.
- (Let me just re-think about “fishing” at this point.. no, I don’t want to explain this.)
5) The user enters the correct email adress and password for guildwars2.com
6) Now (s)he’s clicks on “Generate new API key” and is being asked what information to provide for the application.
7) The user gets something like “ADSA165DS1V69A8REV6ASDF” and now has to copy this information to clipboard (let’s guess the user has no problem with copy&paste)
8) Now we can return to the application and paste the API Key (..) into the form

I don’t even want to think about those steps for a “level 1 user” with a fresh installed Windows….

Hey Lawton,
I know this discussion was over before it was started, but I don’t think we will be able to write an “everybodys application” with this need of user IT skill.

Cheers,
Chaly

Lawton Campbell.8517:

I’m probably going to put QR codes on the API key management page so that native apps can “copy-paste” the key into the application in a gross but somewhat feasible manner.

Yeah. This has to happen. My API use-case is for mobile devices and, at the very least, you guys providing QR codes will be a big help.

I’m not surprised by the move away from OAuth2. smiley and I have always agreed, and he’s right again, Though, from a business/support standpoint, OAuth2 is untenable; it makes it too easy for players to click-through and grant access to an application without fully understanding the ramifications.

The process with OpenAuth2 needs a few clicks including authentication at guildwars2.com. Everybody should be able to succeed this and it is a well known process.

I totaly agree that most ppl won’t ever read and just click-through. Even “warning, ArenaNet will provide your wallet, inventory, .. Information for a third party application” will be ignored by some users.

Increasing the need of IT skill won’t change anything. The skill needed for copy&paste of a “weird looking” API key is independet of the awareness of data security.

Do it like Android or do it like Apple, but never do it like Microsoft ..

- You can tell the user and hope that (s)he reads and understands.
- You can try to control (have some kind if contract/ agreement between ANet and) the third party application.
- But you won’t ever change the user behaviour/ awareness with the need of increased IT skill. They simple won’t use the feature or follow a guide making them even less understand the consequences.

Cheers

Lawton Campbell.8517:

There are some exceptions to that — I really want to expose guild chat and motd editing and stuff — but for the most part it’ll be read-only everything, so the damage a malicious actor could do is fairly limited.

I would love you sooo much

I have a few comments/suggestions about the new API key system. My primary concern is user drop-off, I’m sure it is in everyone’s best interest to get users through the API generation process as easily as possible…

1) “API Keys” in the left menu – on the plus side most users will probably be able to locate this menu option. It would be better if it was a red button.

2) Name and description for the API key – IMO will confuse most users, they will think there are specific things they need to enter here and most likely will drop off. If they read the text they might figure it out, but as we know most people won’t bother to read more than a few words. Additionally most people won’t understand why they are creating an API key in the first place.

3) The permissions check box. While not a problem now since there is only one permission (“account”). I can see this as a show stopper after new permissions are added. App developers need a way to request a minimal set of permissions (perhaps by passing ids on the querystring).

4) After the key is generated there needs to be a button to copy it to the clipboard. The key is long and the font is small, so there is a high probability that it will be copied incorrectly.

I understand management made the decision to remove OAuth, but this doesn’t add any extra protection against phishing. Given that, I’m not against API keys as an alternative, but there needs to be a way to streamline API key generation and input.

I like the idea that different keys have different permissions, gives the tech-savvy option to protect certain info and deal with a possible uproar about elitism. HOWEVER, the experience of generating the key, setting permissions and then instructing to copy-paste needs to be streamlined. I want a way for users to quickly register their info without having to jump all the hoops, currently it’s just easier for guilds to follow the regular shivtr.com path, because it’s less steps (register, then login on any other guild site you want to apply into). What i propose is enable a ‘Generate API key’ link. The link would redirect to guildwars2.com, then pop up a window with all the permissions the link requests (e.g account, materials, bank) and asks you to accept or refuse, upon success, just redirect to a page that is not cluttered and centers the API key in the web browser in a large font with instructions as to minimalize any PEBCAK. Example of the link would be something like:
https://account.guildwars2.com/account/generate-api-key?perm=account+bank+materials
As far as phishing concerns go, i think nothing changes, if this does not take effect, i’m still going to redirect people to account.guildwars2.com but i wont be able to hold their hand once they get there.

@Sylfer: Sadly it was already said that there will be no link to generate keys: https://forum-en.gw2archive.eu/forum/community/api/HEADS-UP-OAuth2-being-replaced-next-week/first#post5033388

I was only reading here up until now, but since I am now getting back into developing API tools I think I need to voice my opionion:

Generally I think it is a very bad way to let users generate their API key themself needing to set all the right permissions as this is very prone to errors. This is especially true when there is no way of helping them trought the process. In case of incorrect API permissions some people would probably be fast to claim that apps simply aren’t working and just forget about them (even when the apps would clearly tell the user that his permissions are just wrong, I’ve seen that already and enough of it) which would hurt us developers too.

Since the generation-link proposal was already dismissed how about atleast the feature to let people enter a character representation of the needed flags. For example, when we have sufficient flags just bring them into a binary string and convert this into base64 or even just a normal A-Za-z0-9 interpretation. This way the apps could tell the user to enter “Adz9s2” into a box that will tick the correct boxes (ofcourse this would need some kind of checksum to ensure that typos won’t alter the flags). We could then have an non authenticated API that we feed what flags we need and get the string-representation back to ensure that everyone has the correct strings and we don’t need to depend this on third-party-libraries or selfcoding.

This way we could atleast guide users trought the process, telling them what to enter where. Also, yes I realize that this will still need the users to verify what permissions they will give, but really there’s not much difference to just telling them what to tick, because those who know about risks will check permissions anyway and those who don’t wouldn’t probably understand the impact of the permissions they are giving and just click whatever we tell them.

What about incorporating the flags into the API key generation itself? Check some checkboxes, make a binary representation of the checked flags, append it to the API key after the key was generated. So we could say "Make sure to enable Account, Material, Bank permissions {image}. Make sure the key generated ends with ‘001’ {image} "? So the key creation form would look like:

• Key name
  List of checkboxes:
• Account
• Materials
• Bank

Then it would result in something like this after appending the flag part:
EE6E6BCE-F25F-9B40-B867-4AC09999990ED0F96997-EFB6-469D-A4C9-E5783E8E7D30-001

I’m also a out of my depth and didn’t quite understand slashy’s proposal, i’m not 100% sure what auth tokens have to look like. What is the purpose of converting the flags binary representation into base64? Wouldn’t it just be easier to append tiny binary string at the end of the API key or is my approach not actually feasible?

Also i find the description textbox completely irrelevant, name itself is all the description a key should require, anything beyond that will only confuse people.

Please add a copy to clipboard button or something similar. In my initial test, I’ve already had people pasting in the api key plus “account” at the end.

Is there any way I can read from this using AJAX (xmlHTTPRequests)?

$.ajax({
url: ‘https://api.guildwars2.com/v2/account’,
headers: {"Authorization": “Bearer <<Token>>”}
})
.done(function (data) {
console.log(data);
})
.fail(function (jqXHR, textStatus) {
alert("error: " + textStatus);
});

Gives me errors

Lawton Campbell.8517:

AllIsVain.6409:

Is there any way I can read from this using AJAX (xmlHTTPRequests)?

It’s not really well documented (since it isn’t normally how OAuth2 works, but) you can alternatively pass the API key via the ?access_key parameter instead of a header. The header’s what’s breaking the CORS restrictions.

I’ve tried requesting the page:
https://api.guildwars2.com/v2/account?access_key=<<Access Key>>

But I get:
{"text":“endpoint requires authentication”}

Is this just not meant to be?

EDIT: Fixed it myself, you need to use “?access_token=” not “?access_key=”

I don’t suppose it would be possible to put up a temporary oauth2 endpoint that would allow us to get api keys for everybody we have a token for?

It would just make it a bit easier on my 830+ users …

Would you consider removing the description field from the “New Key” form? Removing it will mean one fewer thing that might confuse an end user. Surely a key name would suffice.

If your intention is to not have 3rd party sites link to login pages, i don’t expect 3rd party sites that are safe will not just link to https://account.guildwars2.com/account/api-keys/create

The sites that do want to steal you account info wont even care and just still link to their login page instead (you expect the user to know how the authentication process work?)

Anyway it seems you are set on the change so i better just get on with the annoying process of writing/recording tutorials

Btw if anyone need an example of how it can be done in PHP, feel free to use this or create your own
https://github.com/iamdansker/Far-Shiverpeaks-Development/blob/master/fsp/authentication/GW2APIKeyIntegration.php

For those unable to use curl, smiley.1438’s previous api tools can be repurposed for this.

Original request.inc.php: https://github.com/codemasher/gw2api-tools/blob/master/inc/request.inc.php

With modifications to send api key: https://gist.github.com/moturdrn/111b8d08c1ee430d0185

I Am Dansker.7105:

If your intention is to not have 3rd party sites link to login pages, i don’t expect 3rd party sites that are safe will not just link to https://account.guildwars2.com/account/api-keys/create

The sites that do want to steal you account info wont even care and just still link to their login page instead (you expect the user to know how the authentication process work?)

Anyway it seems you are set on the change so i better just get on with the annoying process of writing/recording tutorials

Fun fact: this was a point i made in the #gww IRC yesterday, transscript below:

[20:30] <Smiley_> the problem with the oauth redirect actually isn’t that a 3rd-party redirects to a login-page but that the owner of the login page has to make sure that the users can easily identify phishing attempts (ssl server certificate)
[20:31] <Smiley_> (by owner of the login page i mean anet)
[20:32] <Smiley_> so when you see a green “Arenanet, Inc.” on the left side of your address bar, you can be pretty sure, you’re not getting phished
[20:33] <relic> I would not rely on users paying attention to the certificate
[20:34] <Smiley_> thats what i meant with “you cannot mitigate PEBCAK” – there are still people who click links on spam emails
[20:34] <Smiley_> natural selection
[20:37] <relic> API keys means that never happens in the first place though
[20:38] <Smiley_> i could easily make up a site which looks exactly like the gw2 account management
[20:38] <Smiley_> in fact, it’s even worse this way
[20:39] <relic> what, so the application links to a faux official site to login to for an api key?
[20:40] <Smiley_> the same which would redirect to a faux official site to login for oauth2 authorization
[20:40] <Smiley_> now tell me whats worse?
[20:43] <relic> both seem equally bad to me
[20:43] <Smiley_> right
[20:43] <Smiley_> so now what’s the advantage of api keys over oauth2?
[20:46] <relic> the user is only vulnerable at the one point they go in to generate an api key right? rather than every app authorization?
[20:47] <Smiley_> ideally you’d have to create a different key for each application, so the risk is potentially the same
[20:49] <relic> sec, I should check the management page lol
[20:51] <relic> but you are doing it from the official website
[20:52] <relic> A faux website couldn’t replicate the keys you manage as well even if they got everything else right
[20:52] <Smiley_> you still have to get there first – how many users do have it open in a tab all the time and how many would just click the lazy link on the 3rd party site “go here to create an api key”
[20:52] <Smiley_> you don’t need to create the key
[20:53] <Smiley_> as a phisher you want the login data
[20:53] <Smiley_> the damage is done in the moment you click “log in” on a faux login site
[20:57] <relic> with oauth, if you are already logged in with a session key, you can authorize immediately
[20:57] <relic> having the person login to a fauz official website seems much harder to phish with
[20:59] <relic> I think that method would happen just as much whether you use oauth or api key :/
[21:00] <Smiley_> right, thats why verified ssl certificates matter
[21:02] <relic> how does that make a difference?
[21:02] <Smiley_> that green thing in the address bar jumps at you
[21:03] <Smiley_> see: https://github.com/
[21:03] <relic> no kitten, what is the difference in regards to oauth and api key methods?
[21:04] <Smiley_> oauth is user friendly, also the token exchange happens between the servers
[21:05] <Smiley_> you have to keep in mind that the api key is basically the access token in oauth2 which noone would see (except the database owner maybe)

Plus: API keys are useless for user authorization, which may be pretty handy for e.g. character websites

smiley.1438:

…

I really hope the web development team will rethink the best practice with the responsible persons …

The new implementation is not best practice to prevent phishing and i hope the team knows that … Do it right not lazy.

There’s a very large difference between one-off processes (API keys) vs. doing something multiple times a day (OAuth2 for authentication). Acclimating your users to have to log in all the time makes it easy for even some of the ones that pay attention to that stuff to make a mistake.

Remfin.4892:

There’s a very large difference between one-off processes (API keys) vs. doing something multiple times a day (OAuth2 for authentication). Acclimating your users to have to log in all the time makes it easy for even some of the ones that pay attention to that stuff to make a mistake.

You only have to log in once with OAuth2 if you give the application permission to refresh its authentication key.

Remfin.4892:

There’s a very large difference between one-off processes (API keys) vs. doing something multiple times a day (OAuth2 for authentication). Acclimating your users to have to log in all the time makes it easy for even some of the ones that pay attention to that stuff to make a mistake.

As already mentioned, this isn’t true
You should already know this as you were the one who pointed out that refresh tokens wouldn’t be very useful if they expired after a day https://forum-en.gw2archive.eu/forum/community/api/Launching-v2-account-w-Authentication/page/2#post4843172

The only difference that actually means something between OAuth2 and the API Key system. Is that in OAuth2, the clients browser will convey the required information after login, however in the API Key system, the user will have to convey the required information after login

That is the only difference and it doesn’t do anything in terms of security, it only makes it harder for everyone involved

Disclaimer, i know that OAuth2 has refresh tokens and the 3rd party site need to request a refresh token from the guildwars2.com api with the information returned by the client browser, etc, but it doesn’t mean anything in terms of functionallity when comparing it to the API Key system

Authentication, as in login-style usage, which has to happen constantly. Not getting keys in the first place for API calls.

OAuth2 “supports” and enables the login-style usage, and there’s no real way to disable it, so it will get used. API keys absolutely don’t let you do that. There is a pretty big difference.

Remfin.4892:

Authentication, as in login-style usage, which has to happen constantly. Not getting keys in the first place for API calls.

OAuth2 “supports” and enables the login-style usage, and there’s no real way to disable it, so it will get used. API keys absolutely don’t let you do that. There is a pretty big difference.

Just to get this straight, you are talking about 3rd party websites intentionally using the OAuth2 authentication from GW2, every time a user has to login to their site?

I Am Dansker.7105:

Remfin.4892:

Authentication, as in login-style usage, which has to happen constantly. Not getting keys in the first place for API calls.

OAuth2 “supports” and enables the login-style usage, and there’s no real way to disable it, so it will get used. API keys absolutely don’t let you do that. There is a pretty big difference.

Just to get this straight, you are talking about 3rd party websites intentionally using the OAuth2 authentication from GW2, every time a user has to login to their site?

Yes

I see there’s now 2 permissions and one is optional, however, during API key edit, you can’t change the permissions, you can only edit the name. Not sure if it’s on the to-do-list or an oversight.

Lawton Campbell.8517:

I haven’t decided whether or not it’s something we should fix, since having a fixed permission set seems like it would be more straightforward for application developers (e.g., if you’ve got a key, it’ll continue working until it’s entirely revoked).

On the flip side, I can see two things happening:
1) New APIs with new scopes keep getting generated
2) Fan site keeps expanding what it can do for a user over time, needing new scopes.

Having to keep re-issuing a key could get onerous. Also, well designed sites are going to have to (somewhat) gracefully handle being given an API with inadequate scoping when it’s first recieved anyways. I don’t see it as that large of a stretch to deal with it again down the road.