0

I am working on a small web app. It automates one accounting process.

I drafted a business requirements and a SOA structure, but due to my limitation, I can't go further, especially the authorization part.

One thing confuses me is should I use RESTful API to do authorization(not authentication)? or Should I do authorization(user-> role-> allowed actions) at back-end, without exposing this authorization service?

What's the best practice here for SOA + RESTful API to deal with authorization?

Sincerely, Nicolas

Nicolas S.Xu
  • 13,794
  • 31
  • 84
  • 129
  • Coudl you explain more what you mean by _should I use RESTful API to do authorization_ – darkheir Jan 22 '13 at 08:50
  • for example: call /authorize/{...} each time before calling other service API to see if I have the right to access the resource,after user is authenticated with sessionID. Is this how authorization is done? – Nicolas S.Xu Jan 22 '13 at 21:18
  • What level of authorization do you need? do you need to block APIs ? filter data ("row level security") ? something else? – Arnon Rotem-Gal-Oz Jan 23 '13 at 07:24

2 Answers2

1

If I have not misunderstood your question, I think correct thing is that each service request the server may return an access error (or error of not having right to access the resource) or the result of the request.

In JSON the server return something like this

{
"status": "ko",
"error": {
    "number": "xx",
    "msg" ; "error you dont have right to access"
 }

}

And if ok

{
"status": "ok",
"result": {
    ...
 }

}

ferrancr
  • 11
  • 2
1

The thing with a REST API is that you can't log in the user using session for example. Each time the user will try to access a protected ressource he will need to send a token that identifies him along with the request (we use a token to not send the password in the request).

So if even if the user call the method /authorize/{...} you ll need to check again its credentials when an other method will be called sinced there is no logged in state.

So for me the best way to proceeed is:

  1. The user send the request with its username and its token as param
  2. On the server side you check if the token is valid (match the username and hasn't expired)
  3. If the token is valid then the user is who he say he is so you can check its right (if he has access to the ressource)
  4. If he has access then you proceed the request
  5. Else you respond an HTTP error like the 401 (Unauthorized)
darkheir
  • 8,844
  • 6
  • 45
  • 66