Proof of identity rather than authorization

[GraemeF]

I have an application that does not need access to anything in or do
anything to a Twitter account, it just wants proof that the user owns
the account. This doesn't seen to fit with OAuth; the app needs proof
of identity rather than authorization, so in fact OpenID would be more
suitable than OAuth.

Ideally I would be able to get the username and user id from the
Twitter API without getting authorization for anything else. What's
the best way to tackle this?

Cheers,
Graeme.

[Elliott Kember]

Hi Graeme,

I think I'm doing a similar thing - I want to use Twitter as the
registration and login process for my app. Right now, Twitter asks for
approval every time the user logs into the account. Is there a way to
say "remember this application" and then always accept auth requests
from that application in future, like OpenID does?

Long story short, I'm using OAuth like OpenID. Sorry to hijack your
thread, but I think we're after the same thing.

Thanks,
Elliott

[Abraham Williams]

Best practice would be a read only OAuth app and run the verify credentials method.

Previously Twitter (al3x) as spoken against using OAuth as an OpenID flow but I don't know if this is their current stand or not.

--
Abraham Williams | http://the.hackerconundrum.com
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from: Madison Wisconsin United States.

[GraemeF]

Hi Elliott,

This scenario worked well with basic authentication; you could just
delegate the login to Twitter. Now I don't see a way to do it without
requiring the user to create another account so that the token can be
associated with it. I haven't got that far myself, but I think you're
missing the bit where you store the token and reuse it the next time
the user logs in to your app.

In my case, I'm working on a web service to compliment Twitter and
want desktop Twitter clients to be able to access it to store/retrieve
supplementary information about a Twitter account. But if I can't
prove that the user running the client owns the Twitter account then I
can't see a way to avoid making them go through yet another
registration process with my web service.

I suppose an alternative would be to ask the desktop clients for their
tokens and use that to call verify credentials? Feels very wrong, but
I really want to avoid the complication of a duplicate set of accounts
for Twitter users.

Cheers,
G.

P.S. Sorry about my accidental post - my palm slipped onto my laptop
trackpad while I was typing and it clicked send!

[GraemeF]

This worked well with basic authentication because you could just
delegate the login to Twitter. Using OA

On Mar 21, 4:16 pm, Elliott Kember <elliott.kem...@gmail.com> wrote:

[Shannon Whitley]

Very timely. I was thinking through this last night. I may develop a
general application for this purpose.

> > thread, but I think we're after the same thing.- Hide quoted text -
>
> - Show quoted text -

[Ed Finkler]

On Mar 22, 6:17 am, GraemeF <grae...@gmail.com> wrote:
> Hi Elliott,
>
> This scenario worked well with basic authentication; you could just
> delegate the login to Twitter. Now I don't see a way to do it without
> requiring the user to create another account so that the token can be
> associated with it.

Well, Basic Auth still works *now*. I've personally advocated it not
go away ever. If you agree, you may want to make this preference
known.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funk...@gmail.com

[Elliott Kember]

Well, I've had it working for a while now using Rails. All this
solution needs is an "Always authorize this app" button.

The way I do it is: I request an OAuth token, and then call
verify_credentials with it to find out who they are. It seems to work
fine, except it forces the user to click "Allow" every time they log
in.

Here's my code: http://pastie.org/private/wxii1xiujjndzwtl0xxdma

On Mar 23, 12:38 am, Ed Finkler <funkat...@gmail.com> wrote:
> On Mar 22, 6:17 am, GraemeF <grae...@gmail.com> wrote:
>
> > Hi Elliott,
>
> > This scenario worked well with basic authentication; you could just
> > delegate the login to Twitter. Now I don't see a way to do it without
> > requiring the user to create another account so that the token can be
> > associated with it.
>
> Well, Basic Auth still works *now*. I've personally advocated it not
> go away ever. If you agree, you may want to make this preference
> known.
>
> --

> Ed Finklerhttp://funkatron.com

> Twitter:@funkatron
> AIM: funka7ron
> ICQ: 3922133

> XMPP:funkat...@gmail.com

[GraemeF]

If they have to log in before you request authorization, can't you
just store the token with the login credentials (in your db) and use
it next time?

G.

[Elliott Kember]

No - they don't log in before I request authorization. I get their
access token without having any idea who they are.

That's what I'm trying to avoid - I don't want to have any login stuff
on my side so the login is as easy as possible.

[Graeme Foster]

2009/3/26 Elliott Kember <elliott...@gmail.com>

No - they don't log in before I request authorization. I get their
access token without having any idea who they are.

That's what I'm trying to avoid - I don't want to have any login stuff
on my side so the login is as easy as possible.

I see - exactly the same problem as me then. When you said they log in I incorrectly assumed you meant to your app.

G.

[Elliott Kember]

Cool - yeah sorry about that. I meant to say the next time they try to
access their account.

It'd be even better if there were another level of OAuth permissions -
"authorization only" - which just lets you log in using the account,
and only lets you call verify_credentials.

Am I the only one that thinks this could be really cool? What are the
downsides?

On Mar 26, 5:07 pm, Graeme Foster <grae...@gmail.com> wrote:
> 2009/3/26 Elliott Kember <elliott.kem...@gmail.com>

[Graeme Foster]

2009/3/26 Elliott Kember <elliott...@gmail.com>

Cool - yeah sorry about that. I meant to say the next time they try to
access their account.

It'd be even better if there were another level of OAuth permissions -
"authorization only" - which just lets you log in using the account,
and only lets you call verify_credentials.

Am I the only one that thinks this could be really cool? What are the
downsides?

That doesn't help, does it? You still need to get permission every time unless you can store your OAuth token for the next time, which is what we are trying to avoid.

In my case I am providing a service for other clients to call, so I think the following would do:

1. Client app gets hold of an OAuth token as usual
2. Client app calls get_id_token on the Twitter API, Twitter returns an "id token" (essentially what you described)
3. Client app passes the id token to my web service
4. My web service calls get_id, passing in the id_token, on the Twitter API, Twitter returns the user name/id/whatever

Unfortunately none of the API functions or the id token exist at the moment :P

The best solution with the API that is out there today is to get the client app to pass its own token to my web service - giving my web service far more access than it needs - which kinda defeats the purpose of introducing OAuth in the first place.

G.

[Chad Etzel]

Won't have "read only access" accomplish this? You can check
verify_credentials and never check anything else... but the OAuth
login flow remains the same..

..or am I missing something?
-Chad

[Graeme Foster]

2009/3/26 Chad Etzel <jazz...@gmail.com>

Won't have "read only access" accomplish this?  You can check
verify_credentials and never check anything else... but the OAuth
login flow remains the same..

..or am I missing something?
-Chad

We're trying to work out how to avoid a second OAuth login and authorization just to check the identity of the user. The problem is that neither of us have anywhere to store the token and so would require a new authorization every time the service is used.

If the client app can request another token (keeping its own, potentially full access, token) and pass it to my web service, then yes, I suppose so... But is that possible? I don't know.

G.

[Joshua Perry]

OAuth is a delegation API, it will never have support for Authentication
only (authentication is verifying identity, authorization is validating
access to some resource based on that identity). That is the job of
OpenID and is a service much better provided for by OpenID.

That said, it would be interesting to see Twitter be an OpenID provider.

[Chad Etzel]

If you don't have a database storing the access tokens or indefinite
sessions on your webserver storing them, then the user will have to
login everytime. There's no way to get an access token without users
going through the OAuth detour.
-Chad

[Graeme Foster]

2009/3/26 Joshua Perry <jo...@6bit.com>

OAuth is a delegation API, it will never have support for Authentication
only (authentication is verifying identity, authorization is validating
access to some resource based on that identity).  That is the job of
OpenID and is a service much better provided for by OpenID.

I totally appreciate that, hence the subject of this discussion ;)

Just trying to work out what we can do with the tools at our disposal. Given that Twitter provides a verify_credentials method that can be called with the appropriate token, that's about the best we can do at the moment.

G.

[Abraham Williams]

The OpenID OAuth hybrid that Google and Plaxo have been working on would be just about perfect for this: http://googledataapis.blogspot.com/2009/01/bringing-openid-and-oauth-together.html

[Graeme Foster]

2009/3/26 Chad Etzel <jazz...@gmail.com>

If you don't have a database storing the access tokens or indefinite
sessions on your webserver storing them, then the user will have to
login everytime.  There's no way to get an access token without users
going through the OAuth detour.
-Chad

In my case I want the client app that is getting and storing its own token to be able to hand something to my web service so the user doesn't have to authorize twice.

G.

[Elliott Kember]

> If you don't have a database storing the access tokens or indefinite
> sessions on your webserver storing them, then the user will have to
> login everytime. There's no way to get an access token without users
> going through the OAuth detour.
> -Chad

That's true - but what if the OAuth detour recognizes that the app is
already registers, and invisibly allows the authorization, and
redirects them to the callback url? For a web-app, this is perfect -
it's an invisible roundtrip, similar to OpenID's one. The user
probably wouldn't even notice.

In effect, I'm re-authorizing every time, and getting a new access
token each time. This will only work for web-apps - but the upside is,
a single button-click and you're logged in.

> Won't have "read only access" accomplish this? You can check
> verify_credentials and never check anything else... but the OAuth
> login flow remains the same..

Sort of - but read-only access can still read DM messages, right? I'm
not sure that's necessary for just logging in.

On Mar 26, 9:11 pm, Graeme Foster <grae...@gmail.com> wrote:
> 2009/3/26 Chad Etzel <jazzyc...@gmail.com>

[Chad Etzel]

On Thu, Mar 26, 2009 at 7:30 PM, Elliott Kember
<elliott...@gmail.com> wrote:
>
>> If you don't have a database storing the access tokens or indefinite
>> sessions on your webserver storing them, then the user will have to
>> login everytime. There's no way to get an access token without users
>> going through the OAuth detour.
>> -Chad
>
> That's true - but what if the OAuth detour recognizes that the app is
> already registers, and invisibly allows the authorization, and
> redirects them to the callback url? For a web-app, this is perfect -
> it's an invisible roundtrip, similar to OpenID's one. The user
> probably wouldn't even notice.

I guess that would work if the user is already logged into twitter's
website and has an active cookie/session going on... but what if they
want to login as another user? The auto-callback wouldn't let them do
that... They'd have to log out of twitter's website first, but how
would they be informed to do that?
-Chad

[Elliott Kember]

Well, on my site I'll say something like "If you're logged in to
Twitter already, click here to log in." It works the same way as with
OpenID.

If they aren't logged into Twitter, they're prompted for their
username and password at Twitter's site. Then they're taken straight
back to mine.

If they want to log in as another user, they have to log out of
Twitter - the same way I have to log out of Google to use a different
OpenID account.

On Mar 27, 3:23 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
> On Thu, Mar 26, 2009 at 7:30 PM, Elliott Kember
>

[GraemeF]

I think we're getting some movement on this - see this thread:

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/73524da521d3081c?hl=en

Cheers,
G.