Authentication

[Benjamin van der Veen]

What's the best way to handle authentication?

I see this space as addressing two separate problems. First, the problem of identity. Is the request actually coming from the user that it appears to be coming from? Second, the problem of privacy. Is the data being transmitted by the server or client readable by the server/client and no other parties?

On to the methods:

OAuth bears mentioning—I feel like it's kinda complicated for what it is, and seems to be very much tied to the concept of a web browser and the cross domain security policies that they provide. It doesn't seem to be a general solution to API authentication outside of web browsers.

But one of the features of OAuth is pretty widely used in other contexts—request signing. Essentially, there is a shared secret between the client and server, and the signature is a hashed combination of that secret, some salt, the date/time, request parameters, etc. In this way, the shared secret is preserved through the hash. If the hash checks out, the server knows that the client is who it says it is, and the server sends the requested data back. HTTP Digest authentication is essentially a request signing method.

Neither OAuth or the practice of request signing achieves encryption. This must be provided by another technique. SSL, for example, solves the encryption problem with very little hassle.

Another method of establishing a client's identity is HTTP Basic authentication. Preparing an HTTP request with a Basic authentication header is very simple, and the username and/or password represents a shared secret between the client and the server. But, that secret is only safe if it is transmitted over an encrypted channel such as SSL.

It seems to me that any time you must prove your identity to a server (by way of an API key or username/password or whatever mechanism) to access data specific to your identity, you're also going go want to encrypt that data—otherwise the server might as well have offered it up without requiring proof of the connecting client's identity. I'm sure this doesn't hold in all cases—for example maybe the API just wants to keep track of which users are accessing which (otherwise public) resources, perhaps for analytics purposes or whatever.

HTTP Basic+SSL solves both the identity and encryption problems with very little complexity for either server or client. Request signing is complicated and error prone to implement, and must still be used with SSL to achieve privacy, yet is required by several popular APIs.

Some of this post is rhetorical, and I've left out some stuff to stimulate discussion. So my question is: What other methods have you seen/used? What are the advantages/disadvantages of the methods I've mentioned and other methods? In particular, why might you opt for a signing technique vs Basic+SSL?

[Jim Cowart]

By far - I've seen HTTP Basic + SSL the most in my travels.  The consistent "disadvantage" I've run into with HTTP Basic + SSL is compliance concerns on the part of the client.  More than once, rules have changed in that client's industry, demanding things like multi-factor auth - so we end up tacking on our own additions.  However, we support an app for one of our clients which (without going into detail) processes financial transactions - allowing their customers to bulk-upload or single-call-http endpoints to transfer their transactions to our client.  This space, IMO, is an example where request signing makes a lot of sense.  It certainly *is* more complex - but the peace of mind and risk mitigation to the business would seem to outweigh the overhead of implementing it.

So, you mentioned the problems of identity and privacy - I'm wondering if we can add a third: authorization...?  I can break this into a separate thread if you prefer, but I'm very interested to hear how you're handling this as well (i.e. - once you've identified that the user is who they say they are...how do you handle verifying they are authorized to access particular resources, etc.).  I think the abstractions provided in the .NET world are woefully inadequate for the most part, as they are usually tightly coupled to the specific implementation.  However, I've done some reading on the concepts behind claims-based auth and I like the ideas overall (though my preference would be to use a general framework that provides claims-based auth and not have to use AD to accomplish it).  Has anyone come across an approach (or existing lib/tool) that you think works well for managing authorization for various client types (desktop web, mobile devices, back-end services, remote 3rd party services, etc.)?

[Benjamin van der Veen]

On Sep 8, 2011, at 7:07, Jim Cowart <m...@ifandelse.com> wrote:
>
> So, you mentioned the problems of identity and privacy - I'm wondering if we can add a third: authorization...? I can break this into a separate thread if you prefer,

This is also a very interesting problem space, but let's keep this thread just about what's going over the wire; and have that discussion in another thread.

[Jim Cowart]

I found it interesting that github provides both basic auth and OAuth options: http://developer.github.com/v3/#authentication

Perhaps that's a sign of things to come - providing multiple auth mechanisms around the same credential store?