Take the 2-minute tour ×

I'm designing an authorization service that will be queried internally by other public-services that are receving an Authorization header within a request.

This service handles the authorization (a pair of public key (user_id) and private key) and its task is to regenerate the signature (HMAC) -its the only service to know the private key-, so it seemed right to me to identify this as the server resource. Then I considered that there is no authorization resource without a user, so I ended up with this base URI:


I've then designed CRUD operations to handle the authorization, create when a new user is created, update whenever requested, read and delete when the user is deleted.

Note: the User entity is handled by another service, i'm only using this URI to pass in a logical way the public key (since it's strictly related to a user).

I'm not sure how should I query this service from other services to say: "Hey, is this key right?" passing alongside this request all data it needs to regenerate the signature.

So what I need is a way to CHECK the Authorization in a restful way

I've tought something like:

GET /user/:user_id/authorization?signature=SOMETHING&data=JSON-DATA-TO-REGENERATE-KEY

But maybe, we could also see it to be creating a new Authorization resource (also if nothing is returned, it's not a token system) thus making PUT or POST more right for this purpose.

What's your point of view? What is the right approach to handle this kind of situation?

share|improve this question
Why are you reinventing the wheel? Doesn't any of the current scheme suit your needs? Basic, Digest MD5, CERT, SPNEGO? –  Michael-O Nov 2 '12 at 19:39
I don't think you understood what I was asking about. I'm already using SHA1 to generate the HMAC I'm asking about what is a restful way to send this signature to the authorization service (and get a boolean response). Data is sent to allow the service to calculate the HMAC. –  user1543863 Nov 2 '12 at 20:14
I'm designing this system after S3 mechanism because none of standard is applicable to my needs. –  user1543863 Nov 2 '12 at 20:17
Why don't you use a custom response header? Someting like X-S3-Auth. –  Michael-O Nov 3 '12 at 10:27
@Michael-O: because custom response headers may not make it through proxies. –  Marjan Venema Nov 3 '12 at 10:33

3 Answers 3


Never forget that a GET method should be 'safe'. It should not "have the significance of taking an action other than retrieval". In other words, the client "should not request side-effects".

share|improve this answer
Should I consider this request as reqeuesting side-effects? I do need to check if the Authorization header is right... if so the service has to respond with a 200 OK, saying that's ok. How would you do it? –  user1543863 Nov 8 '12 at 16:06

Personally I think that the obtaining initial authorization (the login) for a session/user/whatever should be a POST as it (presumeably) does create something new: some authorization token.

Subsequent authorization validation requests should be GET. They don't create anything new and basically return a boolean (albeit through response codes) to indicate whether the authorization headers are valid or not.

share|improve this answer
I do not create a sessions, each time a request is received I check if the HMAC is valid. You would do a request directly to the service of your interest, creating an HMAC signature, then it will be the service you're dealing with to create an internal call to another service to calculate the HMAC signature, waiting for an answer before to proceed. What do you think that should I use then? –  user1543863 Nov 8 '12 at 16:11
I am no security / authorization expert. I only responded to the question about which verb to use. As far as I understand it the normal flow would be that upon successful authorization you get a security token that you add to the following request. That token will have limited validity, by time and/or number of requests. –  Marjan Venema Nov 8 '12 at 19:41


Are you storing the private key server-side? And are you handling authorization and authentication on the same service?

I would personally prefer an architecture like WebID. See:

share|improve this answer
Yes, I do. The private-key is stored inside a redis database only accessible by this service. Then it is expecting requests from other services, that are this service consumer, passing a HMAC signature and the data needed to regenerate the HMAC signature... It is the only service to know the private key, except the user. I'll read your links, thanks, but I'd like to keep the authorization simple, like S3 solution. I want one service to handle it to avoid duplication between all services that need some sort of authentication. –  user1543863 Nov 8 '12 at 16:15
I'm puzzled by the fact that your architecture requires the private key to be known both by the service and the user. This lights a warning bulb for an asymmetric key system. I think that this design choice has to be reexamined before answering your question since this is coupled with your need to regenerate the signature. –  Aurélien Dec 28 '12 at 13:42
How would you let the client generate the signature if he is not given the private key? Of course the authorization is centralized and only this system is going to know the key. All other services do not. –  user1543863 Jan 11 '13 at 15:49

Your Answer

