How do I restrict access to url's on my site and only allow my client applications to access these urls. I am putting in a rest api to request the url and was thinking I could use public/private key sort of like AWS S3 does. My understanding is that I still need need SSL certificate to secure data during transfer.
Does this seem like a right approach? Also I am unsure on how to go about generating the keys on the server side. I am coding in both rails and php.
I am going use Query Request Authentication to secure the download urls.
http://docs.amazonwebservices.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/index.html?Query_QueryAuth.html
Related
I am building an API and I'm stuck at the authentication part. I will try to explain what I have and what I'm trying to accomplish:
First, the API is closed to the public, it will only be used on the admin's back-end and for 3rd party devices in the company.
I have a model called Member that is being used with Devise for authentication
I'm also using STI to distinguish between 3 levels of users (using CanCan for roles)
What I thought:
I tried the Token authentication by Rails, it worked but I was afraid of expose the token in each Ajax request, I don't know if I was right.
I also tried to use a '/token' route to post my credentials and get a token, but I was facing the same problem in a more complicated approach. The link with the tutorial
I don't wanna use OAuth because it's unnecessary for that kind of application.
Is it secure to use this token authentication with ajax requests or is there a more secure way to prevent people accessing my API?
Token authentication needs to be done over a secure connection.
If for example you are using Heroku, it is possible to use
their credentials to gain a HTTPS url. With this the contents
will be encrypted and so exposing the token through JSON
over the API will be acceptable.
What are the best practices for storing client creds when implementing an OAuth2 provider?
I can store access_token/refresh_token/auth_code as a salted hash (just like passwords) if I decide that every time client requests a new one I issue a new one. But in the case of the client_secret I need to be able to show it along the client_id on the app registration page, so I can't keep only the hash.
Thanks!
Lev
Using a machine generated client secret is only one of many means to authenticate a client application. I assume this is what you want to use in your service. In this case you already answered your question, you have to store the secret in plain text as long as you want to be able to communicate it to application developers at any time.
If this is not acceptable for you, consider choosing a different solution, such as letting the developer set the secret like you would do with a password, and never store the plaintext; or use a private/public key pair authentication scheme like MAC.
I'm just starting reasearch about the best way to implement user authentication within my soon-to-be app.
This is what I have so far:
A desktop (Windows) application on a remote server. That application is accessed locally with a browser (it has a web console and MS SQL Server to store everything).
The application is used with local credendials stored in the DB.
This is what I'd like to accompllish:
Provide access to some information on that SQL Server DB from my app. That access of course must be granted once a user has id himself with valid credentials.
This is what I know so far:
How to create my PHP web service and query info from a DB using JSON.
How to work with AFNetworking libraries to retrieve information.
How to display that info on the app.
What I don't know is which could be the best method to implement user authentication from iOS. Should I send username and password? Should I send some hash? Is there a way to secure the handshake?
I'd for sure appreciate any advise, tip, or recommendation you have from previous experience.
I don't want to just implement it but instead I want to do it as good as possible.
There have been books written on this, so any answer given here is necessary incomplete. So, I'll give you an outline of the simplest thing that actually works. The bare minimum for securing a service like this is to use HTTP Basic Authentication (supported natively by both AFNetworking and PHP) secured by SSL/TLS.
Basic Authentication is a way of hashing (not encrypting) credentials in a standard way and sending them as one of the headers in your request (Authorization: Basic <Base64-encoded concatenated credentials>). AFNetworking supports this as part of its AFHTTPClient class (see the -setAuthorizationHeaderWithUsername:password: method). PHP parses the authentication header into a pair of server variables ($_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW']). From here, you just check the username/password combination against your user database and allow or forbid access to the resource.
The reason it's crucial to pair this technique with HTTPS is that the credential hash is easily reversible; you're basically sending the password in the clear, so it can be grabbed by anyone listening to your traffic. Setting up a certificate and sending your requests over the secure channel prevents this type of vulnerability.
If you want to be a little more sophisticated, two-legged OAuth is also a viable choice for this scenario.
I am building a RESTFul API and wondering what's the best way to do auth? Users will need to authenticate. I know of three ways:
1.) Pass API key in every RESTFul requests:
http://api.mydomain.com/api-key-here/get-users
This is nice because developers can immediately start using the API by simply copying URL string into the browser. Are there any potential security risks though?
2.) Every request passes the API key in the header of the request.
This seems to be more secure, but developers can't make requests via their browser. CURL is required.
3.) oAuth
I must admit I don't know much about it, but seems very popular. My concern is that its a barrier for developers to start using the API. They first must be familiar with oAuth, and have it setup.
Thoughts? Thanks greatly.
If your concern is burdening developers with a high cost to entry, I suggest basic auth, but running your API over https.
I do this with Diligent Street and it works really well. I use an API Key and couple it with a Secret as the username/password combination for basic auth.
I have employed the technique found here: Build a RESTful API. This solution uses an MD5 hash of your API ID, API secret and the UNIX Time stamp and passed in the HTTP header. This authentication method is the same used by Mashery’s Authentication.
This link references and contains a full blown starter kit for creating an API that has Auth, Membership and*API Usage Metering* along with a supporting EF database.
As for testing the service you can use RESTClient to execute HTTP calls with custom headers instead of using Curl.
I am using the Single Access Token from authlogic to sync data from a MS Access Database to a Rails App. Because I sort of think that the URL sort of exposes the single access token, I am uneasy about extended use. I have heard that if one uses basic http authentication, HTTPS is really important for security. Is my case similar?
Thank You!
You'll need HTTPS for authentication security and protection of your data while in transit.
Single access tokens or any other one time use passwords protect you from key loggers or anyone obtaining and using your password since whatever password you used wouldn't work again. However, without HTTPS, it is possible for a man-in-the-middle attack.
Then there's the data you're sending across the wire. If they are not encrypted, they are easily captured in HTTP. In effect, HTTPS provides the data encryption during the transmission.