Auth between frontend service, backend service and DRY databases

[coneybeare]

http://security.stackexchange.com/questions/11204/dry-api-authentication-design-between-services
I just asked this question on security.stackexchange.com, so please
duplicate your answer there if you choose to write one so I can reward
you with reputation points.
------

Basically I am creating an API service that is going to require
authentication. this will be the first part of a project that will
include a front-end service for my website, and also open up the api
for 3rd party client front-ends to the service.

I have been planning out how I am going to split my site into the
backend/frontend and think I have come up with a solution where I
don't have to have duplicate user tables, but wanted to see if there
were any gaping holes in my logic by asking a question here.

The auth system is designed to be similar to the Amazon AWS S3 auth
system — assigning each user a key and secret, then using the secret
to sign the api requests from the front-end clients. The api then
looks up the user from the api_key, verifies that it was signed with
the user's api_secret and goes from there.

The biggest hurdle is that I want my user model to live in the
fronted. This is due to the existing ties between the user,
subscription models and payment information that really have no place
in the API service. To work with this, when the API needs to lookup a
user api_secret, it has to communicate back to my front-end app (over
a secure https line, and a different thread) to get it. This picture
will help explain that in step 4.

http://cloud.coneybeare.net/DmSp

I think that this will provide a secure auth system for the api, and a
way for any front-end client or 3rd party client to implement steps 1
and 2, while not duplicating any user data in the backend. Step 4
would still always call my specific front-end app which holds all the
user tables. Is this a dumb way to do this?

[coneybeare]

Since there is not yet a response, I will rephrase the question in
terms of the book…

Going off of chapter 10 (Security), what is the best way to use HMAC
authentication on an API backend service that has the user model in
the separate frontend service and db? Should i have a service-to-
service lookup call for the user? Or is it better/safer duplicate the
user credentials across the dbs on the fronted and backend?


On Jan 30, 6:37 pm, coneybeare <coneybe...@gmail.com> wrote:
> http://security.stackexchange.com/questions/11204/dry-api-authenticat...

[Paul Dix]

It's really a question of where to put the access token and the secret
key. If you put it in the db for the frontend, you'll need to have an
API call that the API service can use to validate a secret key and
access token.

The API access is associated to users? You could also just use regular
requests over HTTPS using HTTP Basic Auth. Then you have the API
service call over to the front end to verify that it's a valid login.
Depending on how much your API is called you may want to have some
caching of the auth info.

At this point when designing an external facing API, I wouldn't use
the HMAC approach. I think using OAuth 2.0 is a better option since it
was redesigned to be more simple and take advantage of the security
stuff already built into HTTP.

Hope that helps,
Paul

> --
> You received this message because you are subscribed to the Google Groups "Service Oriented Design With Ruby" group.
> To post to this group, send email to service-oriented...@googlegroups.com.
> To unsubscribe from this group, send email to service-oriented-desig...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/service-oriented-design-with-ruby?hl=en.
>

[Matt Coneybeare]

Thanks for the response. I think OAuth is the right call here as well. I am building my frontend on top of the public-facing api with little if any private-api calls between the frontend and the api-service. This means that when a front-end user has signed in, I will be signing the apir requests with their own tokens instead of an application token or private calls. It seems that I would only need 1 private frontend-to-backend api call to return the token and key for an associated frontend user. All users of the backend api will have to have a user account on the frontend anyway, so I can ask the API to generate the keys when a frontend user signs up. Doing this over https, the frontend could get the generated key and token then store them in the frontend db to sign future backend api requests with.

This would provide the auth needed to run the frontend ontop of the public api, while also using the same credentials to allow API access. The only downside I see is that I have to keep duplicate copies of the token and key in user models in both db's, but keeping the API and the frontend separate is important to me (thanks to your book!) so I will have to make do. Was this approach more or less what you were talking about in the last paragraph of your reply?

[Paul Dix]

Yeah, I think that gets at it. You could avoid having to duplicate the
oauth tokens in the respective DBs by just having the API service
store them. I think that makes more sense.