OpenID in the works?

Ok I understand the problem here, Open ID isn't really necisary for devs comfortable with some javascript and serverside scripting.

Had to deal with it too... I think all SOE really needs to do, is give us a way to automagically close a window after successfully logging in.  i.e. say a user is on a fan site, they click a button that opens anew window to log users in to SOE, then on successful login, simply auto close that window.  i.e give us a link to redirect to the login page and then on login redirect, take the user to an auto-close page.

Here's how my implementation works  on Planetside 2 Apps.

1. User comes to the registration page.  
2. onload I initiate a JSONP request to fetch the user's character list.
3. if user is not logged in JSONP request will ERROR, meaning you can add functionality in the error callback.
4. Provide the user with a button and text explaining the process (click this button, login, close the window, in user friendly terms), if the user is already logged in to SOE.com, then skip down to step 8.
5. when user clicks button new window opens with login screen.
6. User logs in and closes window.
7. When window closes, register page auto-refreshes the JSONP request (hint: $(window).focus(function(e){ ... }) is a good way to do that, just make sure you have some logic in place to prevent it from checking every time the window refocuses... that can be annoying and a waste of resources.), should be logged in now but if not, go to step 3.
8. on successful fetch of JSONP data, execute success callback functionality on your website/app however you want.

I use this functionality to make sure all registered users have a valid SOE account and more accurately, valid Planetside2 characters.  though I still need to run some tests with an account that does NOT have an SOE account, but that's details.

The whole process can be seen in action here: <a rel="nofollow" href="http://www.ps2apps.com/register"]http://www.ps2apps.com/register[/url] Please note, the site is still under heavy construction and not really ready for full on public release, otherwsise I would have announced it in the general forum <img src="/station/images/smilies/69934afc394145350659cd7add244ca9.gif" border="0" /> just doing dev work and public feedback atm.
Edit:

Hell, i was even considering making the entire login schema dependant on the SOE login so users don't need to have their own login/psw on the site, but I haven't worked out the full ramifications of doing that yet, so for now it's just part of the registration process.

 

I think I found the right question to ask here...

Is there a page that auto closes when it's reached but requires the user to be logged in to reach it?  something like a window that opens or something?  as long as the login schema can forward to that page on successful login (i.e. make that page the original link) then we'd theoretically be all set.

 

The biggest deal about OpenID (or, oauth) is that the fan site would never, ever have direct access to the password.  Additionally, fan sites could continue using the access token once the user has gone to bed, as the tokens are not tied to a browser or a browser session.

This would be a big benefit for a lot of fan sites, but rules about access to the data and what can be made public would have to be made.  I would just as soon keep public info public, and private under SoE's domain.

 

Once the user authorizes, you can also access all that player's character data any time, just store the character IDs the first time around, then periodically refresh the list when the user logs in.  Only situation this would not apply is if they release (for Planetside 2 atleast since that's what I am building my apps for) more methods requiring the user to have an active SOE cookie in order to interact with critical data that you may want to be able to access when the user is off line, though in PS2 world, I can't see any reason you would need offline data.. it's a very activate state game, and offline data that you would need is already accessable via the api without auth.  the only thing auth gives you for ps2 data is to get that user's characters, which is what every fan site would love to be able to do.  and having those, you have everything you need for all character and related data.

I agree with you that for SOE to implement some sort of OpenID or oauth (probably more likely oauth imo if any) functionality, it would be great for many fan sites.  My point simply is, you can still do a lot with the current method, just takes some work getting it to work properly.

 

While it's technically true you can use JSONP to get this information, it's a bad hack, as are ALL JSONP requests. Period.

They're unsafe for all three parties: caller, service and user.

The caller's security is not a concern here, we probably trust (though maybe we shouldn't) SOE to return valid JSON from this service and that it won't return malicious stuff.

The service, however, is basically allowing the caller to hijack a user's browser and make requests on their behalf. Thus the visitor to the site (user) has to trust the caller (in this case you) to NOT view or get any sensitive information that you ought to not have access to OR post bad information to the service.

This is why cross-site JSON requests are restricted. JSONP is a hack around that. No reputable site should be built on such a method, period. End of story.

There's no way for the visitor to know that that the caller is accessing the site in their behalf, there's no way to revoke access, there's no way for SOE (the service) to know that it isn't the user actually doing the request, etc.

This is somewhat mitigated by the nature of the current SOE design of the API where, really, no private information is available at all, but in reality, SOE should even remove the page that they've provided with the character IDs listed and instead provide OpenID. It's bad design and it will be abused as the poster above has suggested to abuse it. I understand why they did so, since there's no good, official way to do it, but it's the wrong way.

(Furthermore, I will just add, this hack mentioned above still requires the user to register or sign in on your 3rd party site, whereas OpenID allows you to have one less password/login to remember since the authentication is taken care of on SOE's end. And, of course, there's the awkward experience where the window doesn't close that the above poster has mentioned.)

 

When a character is opted out of Census, it is the same as if the character has been deleted. Refreshing the data would not be possible unless you can continue to piggyback that cookie/JSONP indefinitely. It's a very fragile kludge.

I still think a token granted *by* SOE *to* EQ2U for *one account* is the optimal solution. Easy to revoke at the account orfansite level, very difficult to hack, and at best, a hacker gains access to View a few characters that would normally be hidden.

 

I think using oauth2 or the like, which is the Facebook model of "grant access to my data to this app" works best.

For one, it gives that app a limited token to do certain actions on the user's behalf, like read character lists, etc.  Permissions can be requested by the app, and are then enforced on the SOE side once the user grants (or denies) perimssions.  They can also list apps that have access, know when the last access occured, and revoke access at any time.  In addition, SOE would grant access to apps, so if there was an app that did not behave, SOE has a level of enforcement and can deny access to the entire app, should the need arise.

This is exactly what oauth2 is designed for, and should be used.  Rolling its own with a unique token per fan site is the wrong approach entirely.

 

Again, OAuth2 is great. I'd love it if they use it.

However, there's not much private information to gain access to since the service is mostly read-only. Maybe it makes sense when people can protect their stats.

But even in that case, an OpenID+OAuth2 solution (like Google does) is probably what's needed. OAuth2 is not really about IDENTITY as much as it is PERMISSIONS.

I assume, by the way, that you were responding mostly to a "custom token" proposition from above, but I figured I'd respond anyhow. And yes, custom setups in place of things like OpenID and OAuth2, where standards are established, is totally silly.

 

yea it's klunky right now as it is, an oauth method would be the best imo, I was just outlining one way it can be done in the meantime.  no point in holding up fansite functionality because of the lack of a better method

 

Here's a solution I think might work for now as it's much simpler...  allow links like this on the login screen:

https://auth.station.sony.com/login....com%2Fregister

meaning redirect the user back to a certain page when done logging in.

This would make things a lot easier to work with in terms of ways to keep the user flow as user friendly as possible.

hell maybe even something like:

https://auth.station.sony.com/login....com%2Fregister

to include the service ID for tracking or what ever..  thoughts?  I am just talking about a temporary solution here... oauth really should be put in place...

 

There's no need for a "temporary solution" from SOE. Just implement OpenID. It's amazingly, astoundingly simple. It would actually be easier to implement than doing temporary hacks.

OAuth is a great idea, but it's not needed yet and it's a little more complicated to implement. I'd be fine if they used it for identity, but it's just harder to set up because users have to authorize, then you have to make an API call with the OAuth token to get the information you're after which would necessitate creating new API methods to do this with.

 

OpenID would give us so little reward, I don't see a point. Just because something is easy doesn't mean you should do it if it will only meet 1 out of 20 requirements. OAuth looks more far comprehensive.

 

I've already explained the reward, in detail. If you can identify a person's identity then you can personalize their experience and grant/disallow them access to your site, as well as saving them from learning a login/password for your site. 

OAuth literally accomplishes nothing beyond that, at this point. There is no "private" infortmation available via the API that a 3rd party site might want to acceess. There is no write component for the API, so you can't push information, either.

OAuth IS far more comprehensive if there is private data you want to get about people, ongoing private interactions you'd like to retreive, or you would like to be authorized to push data on behalf of a user. There's none of that right now.

In addition, if you use OAuth for identity, which you can do, you need to add MORE API calls to the service above and beyond just adding the OAuth call. OAuth gives permission to retrieve/publish data, so (if it's set up right) you'd have to do the OAuth interaction and then make a call on the user's behalf to get their identity. And that's fine! But it's more work than just doing OpenID or some re-invented custom solution, which was my point. I don't particularly care if they do OpenID or OAuth to solve the problem, just have some solution that's reputable.

Furthermore, OpenID and OAuth are not conflicting whatsoever. They should absolutely have OAuth when there's private data to get or when there's a write API.

I'm not aware of the other "requirements" that demand OAuth  instead of OpenID.

Also, man I hope SOE is at least reading this thread and will chime in at some point. Even a "no, we're not doing any work on this anytime soon" would make for less frustration.

 

Agreed, personally I prefer the oauth implementation strategy.  It's not just about where the system is right now,  it's about where it might go in the future.  it's always bad practice to build something on just the requirements of today.  you need to think ahead if you are going to build a lasting product.  sure the API is read only right now.  but who is to say that implementing outside chat into the games won't be something they decide to do?  or for commanders (for PS2) to have the ability to see the activty on the overhead map on their iPad and issue orders and similar tasks to their outfit/platoon?

There is, semi private date to get.  the character IDs for a specific account.  normally only the logged in person knows what those are.  granted you can't do any damage per say with it (not serious damage anyway), but it's still account specific private information.  I currently use that information in the site I've been building (see my sig), because I need to restrict people to the characters they own because signitures can be customized for one, and also I need to be able to pull that person's character information to allow them to customize their loadouts and what not.

OpenID would be as much of a bandaid as the one I recomended as an 'intrum' solution of a redirct.  But you are right Murcielago, they do just need to implment something.  they need to do (and are doing) a lot of things right now, so for now, I would just work with the workaround method that I came up with or similar versions of it to achieve this same customization of user experiences that we all need.

 

Hey Guys,

After much discussion on our end, we're not currently going to expose a way for 3rd parties to take a look at what characters are owned by a certain user.

This could bring up complications such as users who didn't want certain characters exposed etc.  

Previously I had posted a link which allows you do do this, but we are taking that down.  We are also removing the "users_character" data type for the same reasons.  

cheers,

Joey

 

I'm very glad to have an answer and glad that you guys discussed this in detail, though the result is less helpful than I would have hoped, of course.

I hope, when you have more time to go over it, that you figure out a good way to do this with one of the protocols we've discussed here and make this functionality available to us in a way that works for SOE, users and 3rd parties.<span style="white-space: pre;">

 

Noooooooooo oh man I did so much work reliant on users_character!  I really hope you guys take a second look at this... a lot of folks are doing it securely, and with even more private data...

Atleast I find out now... I guess it's time to re-visit my registration schema... See my problem is, I don't want users to be able to claim characters that are not theirs.  See on the fansite I am building (ps2apps.com) the idea is to customize a user's control over their own characters, not other's characters.. so signitures, outfit specific data like outfit specific signiture backgrounds uploaded by outfit leaders, a customization tool that allows you to customize your character taking into account what it already has an what it doesn't.  I think you could see why I would want to make sure the characters you associate with your account, are indeed yours... I guess I'll just have to also put in a reporting system..... come on guys... Personally... if I authorize a site to know what my characters are... then I authorize them to do so... It's not like I am giving them the ability to use my station cash or worse... And in the form it is now, it's not a persistent connection, it's a one time auth and store, and consequent updates would still require the user's input to authorize the process.

I just hope you guys reconsider... at the very least leave users_character in, I mean it's not exactly the easiest of methods to use heh.. to see the easiest implentation I have been able to figure out for it, see www.ps2apps.com/register.  Though in a few days I assume I'll prob have to re-write that whole schema.... took me a whole day figuring out how to best work with users_character...

 

I feel like I should point out, by the way, if you set this up for each character owning an OpenID URL and used the players login credentials, like I suggested at the top, you wouldn't have this problem.

But, again, no worries. Take your time, do it right, etc.

 

OK.. how about this for a solution then.  instead of taking the users_character OUT entirely.  give it a required parameter, and that is passing the URL the user character's ID for verification of that character belonging to the user.  Atleast that way, we don't get teh full list if they user doesn't want that exposed, and on the other hand those of us running fan sites that need to verify a character belongs to a registered user, get that security as well.

Thoughts JoeyTan?

 

The asumptions I made were I could never securely authenticate a user visiting my site with the SoE database, so I opted for an entirely different solution.

I don't care if you claim character X.  I don't care if 10 different people claim character X.  Let them.  I have exactly one copy of the SoE data for character X, and all other my-site-added value is per-user, per character.  So, if someone makes a banner for character X, that's great.  If someone clicks on it, they get one user's view of that character's config, not "the one" that is somehow considered official.

It works so far.