I need to develop an API to be the core of a web APP.
My initial idea was making a REST API that would treat all the request and then create some clients for web, mobile and desktop.
My question is, How should I manage the authentication for this situation?
I thought about using a token that would be passed with all requests to the REST API.
Im my case, I would not like to have something like OAuth because the ecosystem will not have multiple apps like Facebook/Twitter does.
NOTE: I must have the API separated from the client for web.
In more details, I would request POST /users/auth passing their password and username, and receive an auth token.
Is it a good approach or there is something better?
Agree that Devise is great for the auth in the application. For the API level, 3scale could help a lot (http://www.3scale.net) - it takes care of rate limits, keys, oauth secret distribution, analytics, developer portal and other stuff. There's a ruby plugin to get started here: https://github.com/3scale/3scale_ws_api_for_ruby.
Devise is a fantastic gem that handles authentication in rails apps. It also provides token based authentication. You can find many resources on the web (for example here) explainig how to use it. No doubt it will fit for your situation.
Related
I'm trying to figure out the best way to deploy an API in Amazon API Gateway. I'm getting totally confused about the appropriate authorization to use.
The API will be used by our customers for their own custom developed apps.
We don't need to provide end user authentication. This will be handled on a by our customers, based on the specific requirements for their apps.
What we need to do, is provide a way for our customers apps to authenticate against our API.
My understanding is that I have the following options...
AWS_IAM - This may not be appropriate, adding customer
credentials to our Amazon account.
Cognito User Pool Authorizer -
This seems to mostly be designed for user authorization, rather than
client authorization.
Custom Authorizer - Presumably can be
tailored to our specific requirements, but would need a lot of code
to be built from scratch.
API Key Authentication - Quick and
easy, but doesn't seem particularly secure, to simply rely on a key
header.
I had originally assumed, that there would be some straightforward way to enable OAuth2 Authentication. For our use-case, the "Client Credentials" flow would have been suitable. However from the research I've done, it sounds like OAuth2 Authentication would require a Custom Authorizer Lambda. I'm really not keen on the idea of having to implement a full OAuth2 service, to authenticate the App. It will simply cost too much to build something like this.
Also if we're writing our own full custom OAuth2 Authorizer, and writing all of the functionality for the API itself, I'm not sure how API Gateway is actually providing us any value.
Is there some best practice, or standard for authenticating API clients for API Gateway?
What we need to do doesn't seem like a particularly unusual thing, there must be some standard way people do this.
Any suggestions would be very much appreciated.
We are building a JSON API on top of our Web application, using JSONAPI::Resources to expose endpoints and Doorkeeper to handle user authentication.
Most of our API endpoints will be exposed only to authenticated users, and Doorkeeper will probably do a great job at enforcing that. But we still have a couple endpoints that will not be authenticated: signup, login, account confirmation, and maybe a couple others.
I am worried that letting those API endpoints completely open will expose us to attacks, in the form of spamming new accounts for example.
Maybe I am worrying more than necessary? Do APIs usually let this kind of endpoint unsecure, and add prevention systems like throttling? (Rack::Attack!!!?)
If not, is signing (or encrypting) my requests before sending them to the API server the right approach?
And if that's so, do you have any recommendation, or preferred approach, in doing so?
I tried to Google keywords like "rails api sign request" or "rails api encrypt request", but I'm not sure the results are pertinent, or which one would be recommended.
The first clients that will talk to this API will be Android then iOS applications, and we might add in the future client-side web applications (at the moment, our web application is monolithic and does not use the API).
I have been tasked with creating a Web API for our mobile application and future 3rd parties to use in order to access our data, etc.
That alone is simple enough, but then I need to secure it. Initially, after reading about OAuth and doing some research, I decided to go the home grown token based route utilizing best practices found online for security. My prototype worked wonderfully but unfortunately the company wants to use OAuth since it's a recognizable standard and considered marketable to our clients.
Soooo, after banging my head against multiple walls the past few days I am curious if anyone has an implementation using OAuth as a service provider and then an ASP.NET Web API client as consumer.
The workflow envisioned is that the mobile application would hit the API which in turn would expect token(s) issued from our self-hosted OAuth service provider. I've yet to find any comprehensive documentation or examples online about this. So far everything I've seen is very piecemeal and therefore incredibly frustrating trying to implement anything.
Well - there is the OAuth spec of course (since you seem to like to handcraft things ;)) https://www.rfc-editor.org/rfc/rfc6749 and the corresponding threat model - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-threatmodel-08
Our OAuth2 authZ server / sec library has an implementation as well - I compiled some docs here: https://github.com/thinktecture/Thinktecture.IdentityServer.v2/wiki
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 would like to offer authenticated API access to my web app. The consumers of such a service are typically other web sites/services.
What would be the best method of authenticating these users? OAuth, openID, http authentication?
As so much in our line of work, the answer to "which is best?" is "it depends." :)
HTTP Authentication - If you're already letting clients log in to your service via an ID and password, you'll probably only have to do minimal work to get this to play nicely with your API. If your API is basically mono-purpose and doesn't require detailed permissions, you can get something working fairly quickly here.
API Token - If you want clients to be able to authenticate easily without providing a password (think companies that build a service that interacts with your API; maybe the IT dept. doesn't want the dev. team knowing the passwords; etc.), then attaching a random API token à la GitHub to the user account is probably the quickest way to go. As a bonus, you can supply a method for regenerating the API token without having to change the account password.
OAuth - If you have multiple permissions or want finer-grained control over how and when a client can access your API, OAuth is a pretty good bet (OAuth2 is much easier to work with, IMO, and supports multiple methods of obtaining an access token). Furthermore, many languages have libraries, gems, etc. that will allow them to simplify the OAuth workflow.
I would say the "best" method is oAuth. It's more flexible and it can be application independant for further uses .
I am using oAuth to authenticate my clients (applications).
;)