|Logging in to a RESTful API||Ell Vee Aitch||11/27/11 1:06 PM|
I'm building a REST API to be consumed by a few frontends. These are
I'm wondering about how to handle logins. I want to use access tokens
I could do everything over the REST API, but that would be pretty
I've distilled my thoughts in the following blog post:
From what I've gathered from the screencasts and this newsgroup, I'm
I think the blog post explains why I think OAuth isn't a great fit.
|Re: Logging in to a RESTful API||Sam Ramji (email@example.com)||11/27/11 8:35 PM|
It sounds like you are in control of all of the clients ("frontends") and therefore don't need OAuth. Is that right?
To be OAuth-ready (as you indicate in your post), option 1 makes sense to me - that way you are building the REST API to be the right construct, and separating the token-granting mechanism early on.
You can replace or augment the token-granting mechanism later on. Presumably you will pass all your tokens (early/custom and eventual/OAuth) in the HTTP header, so even your proxies/web infrastructure can be trained from an early age to behave well.
|Re: Logging in to a RESTful API||Ell Vee Aitch||11/28/11 4:46 AM|
On Nov 28, 5:35 am, Sam Ramji <sra...@apigee.com> wrote:
Yep. They're static sites being served by us. Basically we're teaching
> To be OAuth-ready (as you indicate in your post), option 1 makes sense to
Cool. That sounds reasonable. I can always move to 2b (minus the part
> You can replace or augment the token-granting mechanism later on.
I considered OAuth because they do explicitly support a flow for user-
|Re: Logging in to a RESTful API||Jeff Schmidt||11/28/11 6:25 AM|
I think it's best to keep separate the authentication/authorization
Of course, the client must deal with the security issues that must be
Another important consideration is to keep your API, and identity
I think your option 1 is best. Do not mix authentication into your
Also, regarding your option 1, with basic authentication, there is no
I don't know what server-side technologies you're using, but given
|Re: Logging in to a RESTful API||Jack Repenning||11/28/11 1:46 PM|
On Nov 27, 2011, at 1:06 PM, Ell Vee Aitch wrote:
> I've distilled my thoughts in the following blog post:
I think there's a third possibility, although you might see this as just a variant of "REST with shortcuts." What we do is this:
1. Every REST call can potentially include user credentials. If they're provided, we check 'em.
In this way, there's no explicit requirement for a separate log-on activity: any request achieves that. We actually do provide a login function, but it's really redundant; within our framework (Rails), it's a null function that gets the universal "check credentials" before_hook, and then does nothing. Violates your quoted Pythonic koan "only one obvious way" rule, of course, but it's been amazingly complicated to explain to users "you don't need to log in"!
Your blog includes some comments on the difference between user-ID-as-email, and user-ID-as-generated-token. This is a real complication, of course, but I think it's independent of the authentication protocol. Certainly, the objection that this means the API needs to understand two auth algorithms holds very little water: the focus of an API needs to be the convenience of the user, not the API! If there's a natural way to generate and issue these tokens within the work flow of the user's initial establishment of relationship, then issuing a token works (we have "partners," who go through marketing reconciliation and contract dickering and signatures in blood long before they get to anything so picayune as API details, so issuing them a token works, and we do that, and allow that as "user ID" in the credentials). If it's end users flitting through on their way to YouTube, then an extra turn-around to request the token, and some necessity to write it in a Post Note on the monitor, and all that, are unreasonable; let 'em use what they know, their email, and provide a Profile Edit page somewhere to update the email.
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
|Re: Logging in to a RESTful API||Sam Ramji (firstname.lastname@example.org)||11/30/11 12:43 PM|
"The focus of an API needs to be the convenience of the user, not the
API!" - J. Repenning
Now there is the perfect quote. This is the core philosophical
On Nov 28, 1:46 pm, Jack Repenning <repenning.j...@gmail.com> wrote:
|Re: Logging in to a RESTful API||Mike Kelly||11/30/11 12:55 PM|
Focusing on convenience is not always the right approach, it depends
on the context in which your application is being consumed and what
the long/short term objectives are.
Short-run conveniences can actually degrade into significant costs
|Re: Logging in to a RESTful API||Peter Monks||11/30/11 8:14 PM|
Conversely, if your API isn't sufficiently convenient to use, it may not make it to the long term.
|Re: Logging in to a RESTful API||Jack Repenning||11/30/11 9:30 PM|
> Short-run conveniences can actually degrade into significant costs
Which would be very inconvenient for all.
I still hold that empowering the use of the API is why the API exists. "Enlightened, far-thinking, prophetic, optimal, faultless, complete" empowerment is, of course, so much the better.
The best way that a man could test his readiness to encounter the common variety of mankind would be to climb down a chimney into any house at random, and get on as well as possible with the people inside. And that is essentially what each one of us did on the day that he was born.
-- G. K. Chesterton, "Heretics"
|Re: Logging in to a RESTful API||Mike Kelly||12/1/11 12:20 AM|
My point was just that 'focusing on user convenience' is not really an
|Re: Logging in to a RESTful API||Mike Kelly||12/1/11 12:21 AM|
For sure.aneffective rule of thumb because your API design should be a
tradeoffof a number of factors, weighed up in context.
|Re: Logging in to a RESTful API||Gabor||10/8/12 7:44 AM|
The link you provided seems to be broken. Would you care sharing a working one, please? I'm very interested in what you came up with.
|Re: Logging in to a RESTful API||Steven Goff||10/8/12 11:45 AM|
On Monday, November 28, 2011 3:46:24 PM UTC-6, Jack Repenning wrote:On Nov 27, 2011, at 1:06 PM, Ell Vee Aitch wrote:
Jack do you mind elaborating on #2? After basic auth is the key returned to the client for subsequent calls to the API? Do you then compare that to what you have stored for the user? I'm not familiar with the term 'session block', is this http session or is it some state on the client? I imagine you just have this key expire after x minutes of inactivity?
Thanks working on refining my first API and want to confirm I'm understanding correctly.