Your offer to help doesn't mean much, considering it would require providing you access to various things that you're just not going to be getting access to.
(That reminds me, I never did get a final word on exempting the ads)
(That reminds me, I never did get a final word on exempting the ads) | |
Revoking won't be necessary if all you're doing is verifying that they own the account.
| |
Its kind of a needed feature or somebody getting their account compromised would allow somebody else to permanently login as that account on another service.
/tg/station's admin tools use byond account linking and I'd like to not have to go and manually search for and delink accounts whenever an admin gets their byond account compromised from a shitty password. You always invalidate all sessions whenever the user changes their password, that's common security best practice. This should also apply to external sites they logged in to with their byond account. A way to validate a session is required for this. Give it a cooldown, an hour per user or so, sure, but it has to happen. | |
Its the developer's job to handle instances like that. You're not going to be able to reuse a successful login on another site else the implementation is invalid. Unless you're polling the BYOND site every page visit to see if the "session is still valid", then I don't see how you'd be able to invalidate an oauth session other than a logout button on the site.
See, an example: Do you get logged out of sites you signed into with Steam if you log out of steam after you signed in? No, because thats not OAUTH's job. You're thinking about things that would give the provider more tools, which would be giving you a separate session to be used in addition to an API key to poll for data only that user can retrieve. And I don't think this would have any benefit to BYOND. | |
change your stream password and you do get logged out of most sites.
It depends mainly how the site does things internally. | |
You wouldn't be because Steam has no way to communicate to the sites that it happened. The Steam web API gives you no known benefit to using any of the information sent back from the oauth (which is just the steamid)
There's nothing "interally" to be done here, it'd require every site to consistently poll the steam API site or require Valve to send a ping to all sites using the API. This is not feasible. | |
Somepotato wrote:
You wouldn't be because Steam has no way to communicate to the sites that it happened. The Steam web API gives you no known benefit to using any of the information sent back from the oauth (which is just the steamid) So, when you go to those websites that use this, do you think they store your display name/avatar to do that little logged as... in the top corner that 99% of those websites have? Guess what, they don't. They cache it yes, for like 15 minutes to an hour, but other wise they poll from steam api your display name and avatar. And if that pull fails they know the session is invalid. | |
The API to pull the avatar/name is unauthenticated.
| |
Hence why I said "It depends mainly how the site does things internally."
Do they display your steam name in the top corner (a common trope in steam linked sites)? Do they store that on link, store it on session, or just memcache it (or even request it every page load)? | |
Which means that its the site's job to invalidate the session, not Steams or BYONDs (unless byond gets authenticated API requests -- which doesn't hold much use imo)
| |
Alright, steams setup is shit.
| |
This isn't uncommon on sites that JUST provide OAUTH endpoints. In fact, this is de facto. All its meant to do is verify that you are that guy.
| |
The proper way to do this would be to have a api method that returns data about the session key, to be cached, and checked at regular intervals by the site.
The provider need only provide that api endpoint and invalidate all oauth tokens for a user when they change their password. I don't see why you, a goon dev, is arguing against better session security considering your codebase's history with security of accounts. | |
I'm not arguing against security, I'm saying what OAUTH is used for. Verification wouldn't be a bad thing to have on the side but not required.
| |
This is the proper way to do this, anybody doing it any other way is unsecure, and I don't give a rats ass how common it is.
| |
Its not part of the oauth spec so its not "proper" to do anything of what you said since its outside the purview of oauth. There are proposed extensions to get you what you want but nothing is official yet IIRC
| |
This is the proper way to do this, anybody doing it any other way is unsecure, and I don't give a rats ass how common it is. Everyone else is using really shitty passwords so I'm gonna use a really shitty password too. | |
You call it a "spec"
I call it a suggested template that takes certain security issues into account. Anything that takes the same security issues into account is up to spec, because treating anything else in the oauth RFC as anything other than an example is fool hearted. oauth isn't a protocol, it's a template for designing your own protocol, you're not suppose to listen to implementation specific trivialities as if they were rock solid guidelines. | |
If you were supposed to fork OAUTH or HTTP or IRC/etc because they're just "examples" then nothing ever would work
| |
The oauth specs is really just a list of security best practices.
It's a triangle of communication between the oauth provider, oauth client, and the user (person logging in) where you have the user ferry messages between the two (using GET parameters) with direct communication between the provider and client to validate the user's messages.
So, byond as a oauth provider (cheap dirty version that can be expanded later):
Take id:2208473
https://secure.byond.com/login.cgi?url=http://yoursite.com/Make an api endpoint to get info from a byondcert string that validates it (and validates it was generated for a given url) as well as provide info about the user
https://secure.byond.com/validate.cgi?byondcert="stringhere"&url=stringhereBam! done. byond is now a oauth provider. Thats it. All you needed was some way to validate the byondcert is valid, and get the user it belongs to.
Ok, lets expand on that to be more of a proper oauth setup and fix some minor security issues:
Add an api for storing that url in a token. So oauth client (reminder, oauth client is the site trying to validate the user, the user is the actual human being validated) sends a http(s) request to byond with the url, byond returns a token string, oauth client sends the user to login.cgi with urltoken="somestring", and byond side looks up that token in it's database to figure out where to send the client.
Now, take that urltoken api and expand on it, by adding a way to store a secret with byond, that byond returns with validate.cgi. (and lets rename it from urltoken.cgi to oauthtoken.cgi)
so now the flow is:
somesite.com/linkbyondaccount.php:
somesite.com/byondauthreturn.php:
Then the only final thing you need to do, is add an api for taking that byondcert string and getting a more permanent token (and some way to validate it's still valid), these should show up to the user in some website interface, allowing them to revoke them and may even require the oauth client send the user to another interstellar (thats kinda like login.cgi) to ask the user to authorize it.