[security] passing password on identification request?
Anthony Brassac
a.brassac2 at gmail.com
Mon Oct 19 17:13:43 UTC 2009
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 <ve7jtb at ve7jtb.com> 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 <ve7jtb at ve7jtb.com> 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 <
>> sysadmin at shadowsinthegarden.com> 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
>>> security at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-security
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091019/0a372689/attachment-0001.htm>
More information about the security
mailing list