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
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
Cheers,
Jeff