Are you accepting 3rd party openIDs for your web app?

Most people don't have an objection to starting up a browser session to get user confirmation for oAuth.

Though there are ways to completely decouple that as well.

You can also have the website give the user a OTP for registering the app.

Asking the user to enter there openID and password into your app is a huge security violation, and not something that is likely to ever be supported.

John B.
On 2009-10-19, at 2:13 PM, Anthony Brassac wrote:

I see, what's unfortunate is that openId was perfect for the needs of our web application. Unfortunately it won't meet the requirements of our web service, so we may actually choose to write our own system now (seeing as how even oAuth needs manual logging in at some point too). Though I'm surprised that we seem to be the only ones with this problem, is that a technical challenge to make openId more web service friendly or is that just a matter of time?


On Mon, Oct 19, 2009 at 11:40 AM, John Bradley <[email protected]> wrote: The user needs to approve the oAuth access somehow. It only needs to be a web browser if you want to use openID for that.

Sorry for the bad news, but openID requires a browser at this point.

If you are the authenticator for the account and not a third party then there are lots of ways to solve your problem, but you will have to stretch to claim they have any connection to openID.

John B.

On 2009-10-19, at 12:28 PM, Anthony Brassac wrote:

But no matter what, even with oAuth I will need to log in using a web browser at some point in order to get that key/secret combination, won't i? Unless there are providers that offer programmatic log in?

I have a feeling we are going to end up having to write something ourselves :S


On Thu, Oct 15, 2009 at 11:54 AM, John Bradley <[email protected]> wrote: You can have the user authenticate to the oAuth provider via openID if it is a condition of the grant:)

That may be the best way to do it anyway depending on how the app is configured.

John B.

On 2009-10-15, at 12:00 PM, Anthony Brassac wrote:

Thanks all for your replies, oAuth looks like it could do it for us, however it seems management had agreed upon using OpenID (research grant related I think), so I'll have to see what gives. Anyway, I appreciate your support.

On Wed, Oct 14, 2009 at 1:47 AM, SitG Admin <[email protected] > wrote: Users giving there passwords to RPs is what openID is trying to prevent.
That is why passwords are not supported in the redirect.

Hmm . . . minor clarification here, though: users giving passwords *their passwords for the OP* (or otherwise transmitting "in the clear") is not compatible with OpenID.

If the RP wants to ask for another password (one local to that system), e.g. for rarely invoked high levels of access, it *might* be compatible with OpenID (depends on the exact use, but isn't automatically NOT compatible).

The description Anthony gave sounds vaguely like Kerberos (from the MIT dialogue), but my mind is stuffed full of other things right now and I get a bit of a headache just getting some meaning out of roughly half of it (the rest seems beyond me tonight).

-Shade

_______________________________________________
security mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security






Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
security mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security

Reply via email to