I’m working on a Restful API that has some funky security requirements.
- The first is that it needs to be locked down so only registered users can access it
- No problem, have users request a token using credentials to get it, secure call to gettoken with SSL. Have token passed in header to all subsequent calls, verify token on those calls.
- The next is that the registered users need to have a license on their machine for our product, and if it is not there they should be denied usage
- No problem, no license then you are refused.
- The next is that if the user does not have a license but their call is coming from a particular source then they should be allowed to run our product with no license
- Only way I can figure to do it is hand out private keys to each source I have to identify and have them sign something (like their token) so I can verify the source when they call the api, and if it is a source that can have no license then all is good.
- Have to do some strange things to get application to run with no license, but ok, no big deal.
- A consumer of the api indicated that I did not need to do this, and if I just used oAuth all would be fine. Based on this I did a little checking into oAuth. It seems like oAuth lets me take tokens that are authenticated by a remote service, like Twitter or Facebook, tack on authorization information to a request token and go to town. This is all good, although more complicated than the use case I’m dealing with. What I don’t see is that it has a way for me to confirm that a call originated from a specific application. I could be missing something though as oAuth documentation is not all the clear to me.
- Only way I can figure to do it is hand out private keys to each source I have to identify and have them sign something (like their token) so I can verify the source when they call the api, and if it is a source that can have no license then all is good.
Since the api is always authenticated against our own credential store I don’t see where oAuth would give me much upside in above scenario. It handles my first two requirements, but in a more complex manner than I’m already handling them, and doesn’t seem to satisfy the last requirement for source verification, at least not as far as I can tell.