OAuth toolkits for developers? Zen/Taoism?

58 views
Skip to first unread message

woodbomb

unread,
Nov 25, 2011, 7:34:32 PM11/25/11
to API Craft
Sam and Brian,

Great bit of OAuth evangelism. I am nearing API satori (perhaps).

I've seen homebrew authorization schemes that require signature
generation and these were written by the client/app developer. Has
anyone built an OAuth widgets that can be controlled via (API-
like :-)) calls from a particular language?

Sam, you mentioned the book of Zen koans. I presume you're aiming
(without aiming) at more "natural" envirnmentally/locally adapted
APIs. I wonder, however, if the organizational environments in which
developers work are (at least for the time being) more likely to
encourage the kind of approaches that Lao-Tzu had in mind, saying "He
who stands on tiptoes is not steady".

Roy

Sam Ramji

unread,
Nov 27, 2011, 1:10:30 PM11/27/11
to api-...@googlegroups.com
Thanks, Roy ;) I think you're right about most developers' environmental context.  Perhaps specifications that stand on tiptoes are not steady either...

I haven't seen any widgets (meaning UI + app logic) for client developers.  There are Ruby gems and similar libraries in other languages to manage the OAuth interactions.  The challenge is in getting libraries that match the protocol version of the provider.

There's a related challenge with "2-legged" OAuth where your client is Javascript and therefore can't hold secrets in the source code; the secret has to be managed at runtime instead where it's less inspectable.

Cheers,

Sam

Jeff Schmidt

unread,
Nov 27, 2011, 2:11:24 PM11/27/11
to API Craft
Hello:

I cannot speak to the client-side libraries too much, but I'm making
use of Spring Security OAuth (http://www.springsource.org/spring-
security-oauth) within my application. It supports both OAuth 1.0 and
2.0, but I'm using it only for the latter. Of course, Spring and
Spring Security are largely Java technologies, which may or may not be
useful. It provides both Authorization Server and Service Provider
functionality.

Regarding 2-legged OAuth, at least in the 2.0 world, you can make use
of a bearer token. In my application there is no end-user data. But,
there is tenant specific data, features, limits etc. For most of our
APIs, access is directly from the user agent (cross-domain JSONP), and
some from the tenants' application servers. Requests from user agents
are authenticated via a bearer token originally provided by the
tenant. Not only does this indicate the request is valid, but it also
identifies the tenant that authorized the client.

The bearer token is obtained by the tenant's application server, by
providing its client credentials (ID and secret) to the OAuth
authorization server. This is done via HTTPS and the credentials are
maintained between the tenant app server and the authorization server.
The acquired bearer token is then provided by the app server to the
user agent. At this time, we're talking only JavaScript based widgets
running within the user agent that invoke the various APIs. Using
JQuery the bearer token is specified via the bearer_token request
parameter. This token can also be provided via the Authorization
header using the 'bearer' scheme.

In either case, the JavaScript code simply presents the token w/o
concern as to how it was obtained. The user agent is never exposed to
the tenant's credentials. Mechanically though, once the user
establishes a session (possibly even anonymously), the bearer token is
acquired from the authorization server, and returned to the user agent
when the initial page loads, perhaps as an attribute of some <div>
within the returned HTML etc. The bearer token itself has a limited
lifetime (expiration as well as number of uses).

Anyway, I hope this is useful.

Cheers,

Jeff

Jeff Schmidt

unread,
Nov 27, 2011, 2:17:21 PM11/27/11
to API Craft
It does not seem I can edit my post. I forgot to say that, given the
bearer token, the user agent does not have to perform any signature
generation etc. It does not need access to credentials of any kind, so
perhaps this just eliminates your need for a client-side library,
other than one for working with HTTP.

Cheers,

Jeff

Roy Wilson

unread,
Nov 27, 2011, 2:29:10 PM11/27/11
to api-...@googlegroups.com
Thanks, Sam, for the tip re Ruby.
--
Roy Wilson
email: anw...@gmail.com




Roy Wilson

unread,
Nov 27, 2011, 2:29:47 PM11/27/11
to api-...@googlegroups.com
Thanks, Jeff. 
Reply all
Reply to author
Forward
0 new messages