Hi, I'm investigating using OAuth to solve some problems in a way that I can't find any precedent for online, which either means I'm an innovator on the cutting edge of the web, completely barking mad, or incapable of using Google. I'm hoping someone can tell me which.
I work for a large organisation in which we have teams independently developing various different web apps that sit on a variety of platforms and technologies. Many of our users interact with lots of these systems at once. Some of them have implemented OpenID and as a result many of our users have OpenIDs. The problems we have are that: 1. Users still have lots of passwords on various different systems 2. We have copies of the same user's account data (firstname, surname, email etc) in many different apps 3. We regularly waste time developing full-featured authentication layers (activation, captcha, forgotten your password etc etc) for app after app. 4. Features developed as part of one app are sometimes taken out of that project and given their own app to enable those features to be used more widely by the business. Say for example you have a great asset tracking system within department A's intranet. It's identified as a really great piece of software and given its own host so that everyone can make use of it, not just department A. But now department A users have to log into the new app separately to their previously tightly-integrated intranet (even if both implement OpenID, because they'd each track their own sessions). 5. Each app stores and manages its own permissions settings for its users, and this drives our department heads up the wall because they can't easily see what systems person A has access to and what they can do on each one. (1) and (3) we could solve by adopting OpenID or some proprietary equivalent everywhere. SREG sounds like a reasonable solution for (2). I'm more interested in (4) and (5). If every app implements OpenID, you still have to log in. I can imagine the user from my fictional department A thinking 'didn't I do this already?' when presented with yet another openid signin - because they've just signed into a different app with the same openid, and the two apps don't share session state. So... how about we have apps that, when faced with a user that is not authenticated, immediately initiate an OAuth session with a centralised authentication system. This may well then authenticate the user using OpenID, but they only do this once. So most users will start the day by visiting app A, be required to log in, and then visit apps B, C and D and use them seemingly without having to log in at all. Have I understood OAuth correctly in saying that this is possible, and am I just reinventing OpenID? Is it feasible to initiate OAuth without knowing who the user is yet and whether they've used the app before? This seems to me to also solve my problem (2) better than OpenID alone, because part of the dataset made available to apps by the OAuth provider can include the user's company ID number, their department code, phone extension and other internal structured data. It's also a better solution to problem (3) because you can add it to a new app without needing to create any user interfaces (and therefore retrofit existing apps fairly easily) Finally if the data that we're granting access to with OAuth is the user's own profile data, it could be their permissions data as well, so provided that the consumer app is prepared to trust the provider to dictate what its users can and can't do, it should be able to delegate permissions management to the provider and solve problem (5). Result: all our users log in just once a day, there's a single master version of their profile data, department heads can configure a new hire's access to all the apps that they'll need from a single interface, and this glorious utopia can be achieved without our PHP developers having to talk to the Java guys. Question: am I barking up the right tree here? Trust this is on topic. Apologies if not. Cheers, Andrew --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
