REST API Authentication Help

[redskins80]

Hello guys,

Im trying to create an SMS API but i dont seem to understand how to authenticate a developers app.

The registered developer has been assigned an Dev ID (API Key) and an API Secret. Now obviously sending both these params using POST is a bad idea since any user of any app created by this developer can see this info being passed.

What i plan to do is, somehow get the app to pass on the key, and somehow authenticate the originating developer account, and create a session based auth token which is valid only for that particular app instance calling the API.

Its just that i dont know the finer details about how to get this done. Any help is appreciated. I dont even know if this is the right way or not.

Thanks!

[redskins80]

In Addition:

I do NOT plan to use SSL/TLS

[Jesse Emery]

If you have a key/secret scheme that sounds like OAuth 1.0a, where the secret is used to "sign" the requests, rather than being passed in the requests (as you point out, that would be self-defeating). I would strongly recommend using existing open source libraries for the client/server ends of the signing, rather than trying to do this yourself.

[sune jakobsson]

Read the appendix in the OMA specification, in appendix G, where the OAuth 2.0 scope is defined.

Sune

[redskins80]

alright ill definitely check that out.

btw, is using sessions a bad idea? That way according to a particular SESSID an access token can be associated and maintained.

[sune jakobsson]

Using Oauth  that is a standard and works and has libraries, would improve the acceptance.

Else you are creating some obscure scheme, that a hacker might find funny to break.

Sune

[redskins80]

Ok so cookies/session is out of the question cuz its way better to use something that's a standard.

But here's what i don't get about the OAuth 'dance' as its called.

I read this presentation http://www.slideshare.net/coldfumonkeh/oauth-demystified-hopefully (Slide 71 to 80), and it seems pretty clear to me now. The only doubt that i have is that the 'triangle' of user, consumer, provider in my case isn't quite complete.

What i mean by that is, in the case of lets say, LinkedIn trying to make some app which helps users associate their LinkedIn acc with twitter, OAuth makes complete sense. Because LinkedIn needs to get resources from twitter ON THE USERS BEHALF (Cuz the user HAS A TWITTER ACCOUNT). In my case, only the consumer has a developer account registered with my service. The end-user doesn't have any credentials for the consumer to ask on behalf of. So how can i implement Oauth? So what will the consumer ask the provider? Will it only state that "watch out, here i come?". Cuz that seems pretty pointless unless its asking a request token for an access token. But in this case since the end user doesnt even have an account, the steps seem useless.

Im really sorry if ive missed out something extremely crucial which makes what im saying quite dumb. I do apologize in that case.
Thanks for all the help.
(PS, apologies for the 'all caps rage' in the middle, just trying to emphasize those points.) :)

[Richard Berger]

First, thanks for the link to the "oauth-demystified-hopefully" presentation informative and entertaining.  I am not an expert, but I have been pondering exactly the same question that you raise.  Restating your question as "Why do I need oAuth if my API isn't accessing any other API out there - i.e. if there is no third party in the dance?".   Since you are providing an API, I am assuming that you will have developers writing applications against your API, or extending their applications by adding your SMS capabilities to their app.  Thus, they will have users (Fred in the case of the "oauth-demystified-hopefully" scenario), their application/web client/consumer plays the role of "LinkedIn" and you are playing the role of "Twitter" protecting access to the resources behind your API.  Thus, these developers and their apps will need some way to get access to Fred's SMS info (stored in your world) and if you implement oAuth "server" then you can make this work.  I have been going in this direction, working with Restlet and its OAuth extension.  Pretty well described at:  https://labs.ericsson.com/apis/oauth2-framework/documentation

Now, one of the assumptions I made was that there are developers who are writing code against your API.  If your API was essentially "internal", that is that you are the one writing all the applications that are accessing the API, then you would probably be able to do without oAuth.

Disclaimer: I am still quite new in this world, so I could be quite confused - so I offer my apologies in advance.

Enjoy,

RB

[Jeff Schmidt]

In my case, I'm providing services for subscribing tenants
(applications/developers/consumers). These services are based on our
own content, plus tenant content that is uploaded and associated with
our content. There is no end user data within our application, and
thus there is no need for user delegated authorization.

But, we still need to support both tenant access (updates and
queries), as well as end user access (queries only). To facilitate end
user access, we provide Flash and JavaScript based 'widgets' which can
be easily embedded within the tenant's web application. Or, a tenant
can create their own JavaScript, mobile application etc., and invoke
the APIs directly w/o using our widgets.

So, we have both tenant and end user clients accessing our APIs.  And,
the end users are accessing the APIs using something as transparent as
JavaScript. User agents don't run through some tenant proxy, they
directly invoke our APIs via JSONP. Providing a user agent with
credentials to do signing (like OAuth 1.0a), or for HTTP basic
authentication etc., was not something we wanted to do. Granted,
temporary credentials could be generated for this purpose. But, the
OAuth 2.0 bearer token made more sense for us.

Not only does the bearer have access to the APIs (within limits), the
token also identifies the tenant that issued the token. That way, we
know both which tenant to attribute usage, as well as which tenant's
data to incorporate into the API response. This works well.  But, from
where does the user agent get this token?  In our case, the tenant
application acquires the token on behalf of the user agent, and then
conveys it when the page is loaded.  OAuth 2.0 specifies a client
credentials mechanism by which the tenant application invokes our
OAuth Authorization Server (AS) and provides its client ID and secret
(issued by us), to obtain a bearer token. This token is then passed on
to the user agent.

I believe client credentials has been superseded by HTTP basic
authentication (both over HTTPS), though the former is still
supported. Either way, the tenant in possession of the API key (client
ID) and secret can obtain tokens, either for their own use (server-to-
server) or to hand off to user agents (site visitors/customers).

For us, OAuth 2.0 handles this nicely.  Could we instead have just
created our own authorization API, whereby the tenant uses HTTP basic
authentication to obtain some magic token (UUID say) that we generate
and maintain?  Sure thing, that would have worked, but it would also
have been non-standard; in terms of defining this endpoint, the format
and meaning of the token, how the token is conveyed when making API
calls (Authorization header, request parameter) etc.  I think when
selling your services, keeping with standards is very helpful.  And,
one day we may have end user data, and OAuth has a solution for that
was well. :)

Also, not using cookies and HTTP sessions pertains to more than just
following a standard. I believe one of the tenants of a RESTful API is
that it is stateless.  The client provides everything in the request
the server needs. Sure, a cookie is just another thing in some
respects, but if it is used to identify a chunk of server-side state
(session), then it's going to matter which instance of the service
handles the requests, or forces you to maintain distributed sessions
among your servers, implement sticky load balancing etc. That's just
mechanical though. If the API is dependent on building up some kind of
session state by invoking some sequence of methods etc., then that
adds complexity to the API.

But, even though OAuth itself stands outside of (in front of) your
API, an OAuth bearer token actually is state.  Is it a valid token or
just some random characters provided by the client?  Is the token
expired?  How does the server handling this request know this? In my
case I need to make sure the token is always used by the same source
IP address (not hijacked), as well as count its usage, and perhaps
invalidate the token due to malicious usage detection etc. That's all
state associated with the token. Whichever instance of my API server
receives the request, it must have equal (well, eventually consistent)
access to the token state. That is all security related though, and at
least the APIs themselves do not also have to deal with session state
etc. A homebrew (non-OAuth) security scheme would have the same
problem, so this not a detraction of OAuth per se.

The OAuth dance is not difficult. There are implementations out there
for both Authorization Server and Provider functionality. Or you can
basically outsource it to our friends at Apigee, Mashery etc. I work
in a Java shop, so we're making use of Spring Security OAuth. By
setting up some filters, and providing some persistence for token
data, it's easy to get up and running. I've had to add more to that
given the other restrictions we apply to token usage, but again, I'm
not writing OAuth 2.0 code form scratch. :)

Cheers,

Jeff

On May 26, 3:41 pm, Richard Berger <richardlan...@gmail.com> wrote:
> First, thanks for the link to the "oauth-demystified-hopefully<http://www.slideshare.net/coldfumonkeh/oauth-demystified-hopefully>"

[redskins80]

@Richard Berger: You got my question perfectly and thanks for replying! The thing is, at this moment Im not planning on storing any information on my server. Maybe in the future yes, but as of now, Im only storing statistics for the developer (sms count etc). I understand what ur trying to say and it would make perfect sense if I was storing any info on my server for the user.
Anyway, Thanks for your input! Appreciate it

Cheers,
Arijeet Mukherjee

[redskins80]

Yeah i understand what you mean by the token behaving like a state. I still havent properly looked into OAuth 2.0. But yeah, I agree when you say its all about following a standard otherwise the product gets difficult to sell.

Ive just recently seen this stuff about the 2-legged OAuth and was wondering if you'd know anything about that?

[Richard Berger]

@Arijeet:

So, if you are not storing anything on behalf of the user, then you don't need the user's permission to do anything.  I am presuming however, that you want to track usage by application - in other words, how many messages have been sent by users of application A vs. application B, etc. (this would match the storing of statistics by developer).  It would seem that you could do this with a simpler approach.  Could you provide an API key to each of your developers.  When their application uses your API, it would provide the API key and your backend could then validate the key (as being a legitimate client) and then you can store/retrieve information based on that API key.  

I believe that the API key concept is fairly common.  The idea is that the developer registers at your site for the use of your API, you provide them the key and the secret and they send that back to you when their app makes calls.  (Of course, it all has to be done securely and I haven't done it yet, so I don't have any useful details).

But the bottom line is that all you may need is secure handling of an API key - as long as you are not storing any user data through your API and therefore don't have to get permission to act on the user's behalf.

Hope this helps,

RB 

[Jeff Schmidt]

Take a look at the OAuth 2 Client Credentials Grant (http://
tools.ietf.org/html/draft-ietf-oauth-v2-27#section-4.4).  The OAuth 2
spec is still evolving, so what's stated here may not exactly match
whatever implementation you're using, but it's the same kind of
stuff. :)

2-legged OAuth is where an application (consumer, developer/
application key etc.) issues requests to your APIs for its own
purposes. It is not doing so with the authorization of any particular
end user within your application. It sounds like you're in a situation
similar to mine; tenant applications need to access the APIs, and I
don't keep any end user data. In addition, for my service, a tenant
application can grant access to others (browsers, mobile apps) to our
APIs/content, and the tenant's content within, by obtaining and
providing a bearer token to the user agent.

It sounds like the former is more akin to the 2-legged OAuth scenario;
the tenant application invoking the APIs (server-to-server) with no
user agent or user involvement. What I do in this case, is require the
tenant application to use its issued client ID and secret to obtain a
token of the proper scope, and then use that token when invoking the
APIs on behalf of itself. That's it. No user involvement, no
redirections etc.

Given that the tenant application needs to perform updates to their
content using the APIs, we actually issue two sets of OAuth
credentials to the tenant. One set is used for the 2-legged scenario
just described, and the other is used to obtain tokens to be handed
off to user agents. In the latter case, the client ID has read-only
access, and is able to access only a subset of the APIs. If these
credentials got away from the tenant somehow, tokens cannot be
generated that could be use to modify content.

[redskins80]

The oauthv2 draft was really helpful. explains quite a lot in detail. Ill be following that to stay within the standards and rules. So basically, what you said about the 2 legged oauth and the app requesting for a token along with credentials and then being responded by a access token, seems to be the way to go. Up till now i was thinking that to ensure security, i must use atleast a 2 step authentication process. Something like... 1- App requests for request token. 2- Server notes timestamp and sends back an request token. 3- The app at this point MUST request again within a certain timeframe along with credentials. 4- The server checks whether the request has been sent within allowed time and authenticates the user and finally responds with a access token.
Even though this 2 step procedure might seem like overkill, but till now I thought this was a must thing to do.
(Please do tell me if this 2 step method is actually not violating any standards and could be improved in any way to ensure even more security. Especially MITM attacks.)

So anyways, thank you so much for taking time ans responding to my queries. Ill go ahead with what you said and follow the guidelines of the draft.

Cheers,
Arijeet

[Jeff Schmidt]

Arijeet:

The basic mechanism is for your app to first provide the client credentials to get a token. The client credentials are the client ID and secret you issued to the application developer. I think later OAuth spec versions prefer HTTP basic authentication over the example below, but I've not moved forward to that yet.  So, for example using curl:

[imac:~/Downloads] jas% curl -d "grant_type=client_credentials&client_id=myclientId&client_secret=mysecret&scope=read,write" "https://somehost.com/oauth/token"

{"access_token":"62bcd0d8-1bad-4a70-9c3b-08ec20a9413f","token_type":"bearer","expires_in":86399,"scope":"write read"}

[imac:~/Downloads] jas%

The client ID and secret authenticated. The client asked for a token with read and write scope. Scopes/permissions etc. are very API specific. The request was made over HTTPS given the sensitive nature of the client credentials (or Authorization header if using basic authentication). The server returns the access token and informs you when it expires (number of seconds from when it created the token). It also indicates the scopes. It's possible you could end up with fewer than you requested.

Anyway, look for some kind of OAuth 2 authorization server (this functionality so far) and provider (API request token verification) to work with your environment, language. It's probably not something you want to do from scratch. :)  I'm using Spring Security OAuth, in a Java environment. I had to write some code to persist the tokens server-side in Cassandra, but Spring Security OAuth takes care of most of the details.

So, that token is good until it expires, or some other server-side policy does not like what you're doing with it.  When your application accesses your APIs, you need to provide that token. You can do so as a request parameter, e.g. access_token=62bcd0d8-1bad-4a70-9c3b-08ec20a9413f, or in the Authorization header, "Authorization: Bearer 62bcd0d8-1bad-4a70-9c3b-08ec20a9413f". Both the name of the request parameter as well as the scheme (Bearer) in the Authorization header have changed throughout the various OAuth 2 spec versions, so make sure you know what your particular implementation requires.  I do believe making use of the Authorization header is preferred over the request parameter in the spec. We make cross-domain JSONP calls, and the request parameter is a lot handier.

So, these are equivalent:

[imac:~/Downloads] jas% curl --header "Authorization: bearer 62bcd0d8-1bad-4a70-9c3b-08ec20a9413f" --header "Accept: application/xml" "https://somehost.com/api/rest/v1/partner/products/EG/672"

[imac:~/Downloads] jas% curl --header "Accept: application/xml" "https://somehost.com/api/rest/v1/partner/products/EG/672?access_token=62bcd0d8-1bad-4a70-9c3b-08ec20a9413f"

Your application then can continue to issue API requests using that same token until it expires. You don't have to use the client credentials to get a new token each time etc. But, the four steps you outlined are generally correct:

(1) App provides credentials to get access token. If you still have a valid token, then skip this step.

(2) The OAuth 2 Authorization Server on your side will validate the credentials, scopes etc., and issue the token and associate an expiration time.

(3) The application uses the token from (2) to invoke your APIs. That app could persist this token and skip steps (1) and (2) in the future. The app can see if an error response is returned, and if due to a bad token, go to step (1).

(4) The OAuth 2 provider functionality (e.g. a servlet filter etc.) validates the token. It makes sure the token is known to it, as well as checks the expiration etc. If all is kosher, the request is allowed to proceed to your APIs.

I think you're on the right path. :)

Cheers,

Jeff