If you are preventing people with access to the user's phone from using your REST service in the user's name, then it would be a good idea to find some kind of keyring API on the target OS and have the SDK (or the implementor) store the key there. If you need to do it this way, I find the security level appropriate (just-right-kill). So it might be a good idea to provide some kind of SDK to users so at least they don't have to go through it themselves. This is because you aren't using a protocol level solution (like SSL). Url = is true that this is a bit laborious. One_time_key = nonce + '-' + sha1(nonce+salt+shared_key) So now you have a clean call like this: nonce = generate_secure_password(length: 16) The username field seems like a good place to put the nonce too, since it is part of the auth. Instead of providing seperate "shared secret" and "api key" fields, you can simply use the api key as shared secret, and then use a salt that doesn't change to prevent rainbow table attacks. For improved robustness, I recommend using a random string instead of the timestamp as a "nonce" to prevent replay attacks (two legit requests could be made during the same second). Since the hash provides the security, you could instruct your users to provide the hash as the baseauth password. url = that is not possible, and the transmitted information is not secret, I recommend securing the request with a hash, as you suggested in the token approach.
To prevent accidental multiple execution, you can filter multiple urls or ask users to include a random component ("nonce") in the URL. If can use an SSL connection, that's all there is to it, the connection is secure*. This seems like unnecessary labor for the user with no gains, so I recommend to handle this transparently on your server as you suggested. The only difference is that you are turning the responsibility for the caching to the user. If you dispense a token to the user instead of caching the authentication on your server, you are still doing the same thing: Caching authentication information.
#Ghostlab http auth password#
For example, with BaseAuth, user agents know the password is a password so they don't cache it. This means a lot of "might crop up later" problems are already solved for you. Let me seperate up everything and solve approach each problem in isolation:įor authentication, baseauth has the advantage that it is a mature solution on the protocol level. Considering the shared_secret will wind up being embedded in (at minimum) an iOS application, from which I would assume it can be extracted, is this even offering anything beyond a false sense of security? With a token in hand, clients can acquire resources: curl localhost/posts?api_key=81169d80.įor the simplest call possible, this seems kind of horribly verbose. Is this good enough? Underkill? Overkill? My intention is to only allow calls from known parties, and to prevent calls from being reused verbatim. The "verifier" is returned by: sha1(timestamp + api_key + shared_secret)
The api_key, timestamp and verifier are required by all requests. only grant rights to particular resources or actions), but that seems more appropriate to the OAuth context than my simpler use case.Ĭurrently tokens are acquired like this: curl -X POST localhost/token -data "api_key=81169d80. Tokens can potentially be more flexible in scope (i.e.
#Ghostlab http auth full#
The Basic Auth solution has the advantage of not requiring a full round-trip to the server before requests for content can begin. Is this really any better than just requiring clients to use HTTP Basic Auth on each request and caching calls to the authentication service server-side? Which brings me neatly to my first question: Because the authentication itself occurs via an external webservice over HTTP, I reasoned that we would dispense tokens to avoid repeatedly calling the authentication service. I'm developing a REST API that requires authentication.
0 kommentar(er)
