[security] passing password on identification request?
Allen Tom
atom at yahoo-inc.com
Tue Oct 20 06:34:06 UTC 2009
Hi Anthony -
In OAuth, the user authenticates with a web browser at the user's
Service Provider, almost always by typing in their password into a form
hosted by the SP.
After the user authenticates with the SP, the SP then redirects the
user's browser to the Consumer (another website) with a response. Behind
the scenes, the Consumer then makes a web service call back to the SP to
get an OAuth Access Token, which is the credential that the Consumer can
use in lieu of the password.
After all is said and done, the user's web browser is at the Consumer's
website, and the Consumer has an OAuth credential that can access the
user's data at the Service Provider.
Based on your description, it sounds like you want a way for a user to
pass a credential from an Identity Provider (the OAuth SP) to another
website (Aka the Relying Party or Consumer), and that's exactly what
OAuth is meant to do.
Allen
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 <ve7jtb at ve7jtb.com
> <mailto: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
>> <mailto: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
>>> <mailto: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 <mailto:security at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-security
>>>
>>>
>>
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/dcf75ccd/attachment.htm>
More information about the security
mailing list