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 <[email protected]
<mailto:[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]
<mailto:[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]
<mailto:[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] <mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-security
------------------------------------------------------------------------
_______________________________________________
security mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security
_______________________________________________
security mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security
