Thoughts about ESME API
Dick Hirsch
HTTP POST calls are necessary to send a message to ESME.
Would it be possible to have another send_message method where you
could include the token in the URL. This might be easier for certain
integration scenarios (for example, including SAP's XI) where two
asynchronous calls would be necessary to send a message. Since I
don't know how the server maintains session data between calls, it
might be easier if we just had one call.
D.
Mrinal Wadhwa
Mrinal
Hirsch, Richard
Von: esme...@googlegroups.com [mailto:esme...@googlegroups.com] Im Auftrag von Mrinal Wadhwa
Gesendet: Freitag, 10. Oktober 2008 09:24
An: esme...@googlegroups.com
Betreff: [ESME-dev] Re: Thoughts about ESME API
David Pollak
I'm all for having sessionless calls. We can't do long polling with sessionless calls, but there are a lot of other functions that we could support.
Would it be easier to include the token as a query parameter, in the URL itself (this is insecure as URLs get logged), or as an X-ESME-Token header?
D.
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Ethan Jewett
I haven't posted here before, so apologies for butting in, but I've
been meaning to ask about this for a while ...
Have you considered making OAuth available as a method for handling
credentials? I'm not an expert, but it is a well defined method for
authorization that doesn't expose usernames and passwords to a client
you may or may not trust.
A basic overview of OAuth can be found here: http://oauth.net/about/
It sounds like the token exchange protocols being discussed might be
rehashing problems that open standards communities have already solved
to a certain extent. While OAuth may not address all the issues here
(for example, I don't think it allows for passing a ticket in the
query string), it sounds like it might address a lot of them and there
might be extensions that address the rest.
If there's any way I can help out with evaluating this, I'd be happy
to chip in :-)
Ethan
David Pollak
OAuth is a mechanism for site C (Consumer) to obtain an authentication token from site P (Producer) without giving 'C' your username/password. It also allows you to revoke 'C's authentication without impacting your username/password or the authentication given to any other site.
OAuth does not define how the authentication token is used on 'P'. 'P' can define the mechanism for using the authentication token in any way it wants.
ESME has an authentication token mechanism (it's a precursor to OAuth support and ultimately, OAuth support will come from Lift [the web framework that ESME is built on]). The use of authentication tokens in ESME's REST APIs is orthoganal to the management of those tokens which is what OAuth is about.
Thanks,
David
Ethan Jewett
Thanks a lot for the response. I hadn't seen any mention of Oauth on
the SDN wiki or on this list, so I wasn't sure if it was being
considered. Good to hear that it is!
Is there anything that I can do to help get OAuth up and running
sooner rather than later for token management, and possibly
implemented in the AIR client?
Thanks,
Ethan
On Fri, Oct 10, 2008 at 10:32 AM, David Pollak
David Pollak
David,
Thanks a lot for the response. I hadn't seen any mention of Oauth on
the SDN wiki or on this list, so I wasn't sure if it was being
considered. Good to hear that it is!
Is there anything that I can do to help get OAuth up and running
sooner rather than later for token management,
If you want to look at Lift and see how the PayPal and OpenID stuff is implemented, I'd be grateful for any contributed OAuth code.
and possibly
implemented in the AIR client?
Is there OAuth for AIR? I'd personally rather see some functionality that builds custom AIR clients that have the token pre-installed.
Mrinal Wadhwa
>> Is there OAuth for AIR?
>> I'd personally rather see some functionality that builds custom AIR clients that have the token pre-installed.
Cheers,
Mrinal
David Pollak
I don't completely understand OAuth .. a quick look at http://oauth.net/documentation/getting-started suggests a workflow where a Consumer redirects the User to the Producer's website where the User enters his credentials and is redirected back to the Consumer after authorization and the Consumer now gets a token that it can use to access the User's data ... this flow is fine in case of web app running in the browser that needs access to information from another web app ... but I'm not sure what the workflow for a desktop app will be since there is no equivalent of "redirecting back to the Consumer" if the consumer is a desktop app running in AIR or any other runtime. One ugly way I can think of is using the embedded webkit inside of AIR to take the User to the Producer while keeping him within the desktop app's window and getting authorization that way .. but that is just ugly.
>> Is there OAuth for AIR?Could you elaborate a little bit .. tokens are user specific so in what scenerio would a pre-installed token help? .. my interpretation of this is that the AIR app itself is a user
>> I'd personally rather see some functionality that builds custom AIR clients that have the token pre-installed.
You would only be able to download the AIR app after logging into the web app. The download would be dynamically generated and the authentication token would be part of the downloaded app so that it would start working as soon as it was downloaded without the user having to explicitly create an authentication token.
Hirsch, Richard
D.
________________________________
>> > Collaborative Task Management http://much4.us <http://much4.us/>
>> > Git some: http://github.com/dpp
>> >
>> > >
>> >
>>
>>
>
>
>
> --
> Collaborative Task Management http://much4.us <http://much4.us/>
Lift, the simply functional web framework http://liftweb.net <http://liftweb.net/>
Collaborative Task Management http://much4.us <http://much4.us/>
Lift, the simply functional web framework http://liftweb.net <http://liftweb.net/>
Collaborative Task Management http://much4.us <http://much4.us/>
Ethan Jewett
token as one option for significantly simplifying the authentication
flow, though I think full OAuth or another option should be available
so that people can use arbitrary third-party clients (like Twhirl) as
well.
On the OAuth flow in an AIR application, my understanding is that it
wouldn't be much different from the current situation with the AIR
client. There is a basic view of the UX flow available here
(http://www.flickr.com/photos/holycola/1484973581/) though there may
not be a facility in AIR for the redirect from the web service back to
the AIR app. In this case the user would have to be provided with a
token to manually input in to the AIR app, exactly as happens today.
If you search for "OAuth flow" on Flickr you'll see a lot of examples
of different applications' flows. Yammer is apparently porting their
API and AIR client to OAuth, so I'll be curious to see how they deal
with this.
Regarding OAuth on the AIR client, there is an ActionScript OAuth
library available at http://code.google.com/p/oauth-as3/ I have no
idea how feature-complete it is, but a message on the OAuth mailing
list seemed to indicate that it works.
I'll look at what it would take to contribute to Lift OAuth, though
Scala and Java aren't really my forte. We'll see what happens :-)
Thanks for humoring me.
Ethan
David Pollak
I like the idea of downloading an AIR application with a built-in
token as one option for significantly simplifying the authentication
flow, though I think full OAuth or another option should be available
so that people can use arbitrary third-party clients (like Twhirl) as
well.
With the existing token mechanism, we can support Twhirl. When I do the Twitter APIs, you'll use your user name for the user name and the auth token that you manually generate for the password. Done.
On the OAuth flow in an AIR application, my understanding is that it
wouldn't be much different from the current situation with the AIR
client. There is a basic view of the UX flow available here
(http://www.flickr.com/photos/holycola/1484973581/) though there may
not be a facility in AIR for the redirect from the web service back to
the AIR app. In this case the user would have to be provided with a
token to manually input in to the AIR app, exactly as happens today.
If you search for "OAuth flow" on Flickr you'll see a lot of examples
of different applications' flows. Yammer is apparently porting their
API and AIR client to OAuth, so I'll be curious to see how they deal
with this.
I'm not sure why you're so hot on the OAuth/AIR combination. While it is a little more work to ask the user to click on the "token management" screen and generate a token, then copy and paste it, it's no worse than popping up a built-in browser inside the AIR client and walking through the OAuth process in the AIR client. From a security standpoint, I would not want to teach users that it's okay to log into a browser in an AIR application because they're exposing their username/password to the AIR application, and that's bad security practice.
Ethan Jewett
<feeder.of...@gmail.com> wrote:
>
> I'm not sure why you're so hot on the OAuth/AIR combination.
Yeah, I really don't see OAuth providing any additional functionality
here or improving the user experience. I'd say that there are two
reasons I'm so hot on OAuth as an option for ESME:
1. OAuth as an authentication option will provide standard
interoperability for whatever APIs end up being defined. If we want
instant interoperability with APIs that use OAuth then it might be a
good idea to start considering it and working on it now.
2. OAuth has undergone expert and open security review. I am not a
security expert or even really a meddler, but I trust an open review.
For this reason alone I think OAuth is worth considering. OAuth also
offers two specific security improvements over the current token
exchange flow that I am aware of: (a) it supports use of a digital
signature method rather then sending the actual authentication token
along with the request, which allows OAuth to be used to authenticate
securely over an insecure connection after the initial token exchange
and (b) it supports signing of the request which allows the recipient
to verify that the request has not been modified in transit.
Reason 1 isn't really relevant until an API that already supports
OAuth is defined in ESME, but reason 2 seems immediately relevant.
> While it is a
> little more work to ask the user to click on the "token management" screen
> and generate a token, then copy and paste it, it's no worse than popping up
> a built-in browser inside the AIR client and walking through the OAuth
> process in the AIR client. From a security standpoint, I would not want to
> teach users that it's okay to log into a browser in an AIR application
> because they're exposing their username/password to the AIR application, and
> that's bad security practice.
I just want to clarify that I don't think that using an embedded
browser is the best way to implement the OAuth flow for an AIR client.
It is one possible way. A better method might be calling the system
browser to ask the user to log in and then either relaunching the AIR
app with the access token passed as a parameter or asking the user to
manually enter the access token in the AIR app.
The discussion as to the best authentication flow has taken place on
the OAuth list multiple times and my impression is that people
generally agree with you regarding embedded browsers.
I also want to clarify something: I haven't really contributed to the
project at all and I realize that suggestions of this nature can
appear presumptuous. If the group would prefer I keep my big mouth
shut until I've submitted a patch or something then please let me
know. I don't have a vested interest in this, so I'm open to being
told to buzz off as long as the invitation to make myself scare is
clear. :-)