I am writing an API to use with my mobile app. I want to use Api Key authentication.
In this kind of system, should I give an api key to each user? Or should I only give Api Key per application that connects to the API?
The reason that I asked that is:
If I give every user api key and authenticate them by their api key, authenticated user will be only one, and I can make requests like /reviews/ and server will return all reviews which are done by authenticated user.
On the other hand, the app will authenticate to use the api, and I should make request like "/reviews?userId=23842374283423".
Which one is the most used type of authentication?
Normally the API keys are issued to the developer who consumes the API rather than the application. Although in most cases each key is used only for one application, in theory you could have another one using the same key. I would recommend going for the second approach.
Related
I have used Auth0 for a while with success, I recently came across a new challenge: allowing external developers to access my API with credentials provided by my web app.
The current system comprises of:
a Web App (not a SPA currently) with Auth0 log in
a back end API with Auth0 api authentication
Currently there is a single client in Auth0. The user logs in on the website and when they call the API via the website the token is passed along in the headers.
My question is: what is the best way to allow developers to request direct access to the api, in a self service manner on my website?
I see two paths forward, either create a client for each developer application via the Auth0 management API (github style), or request a token on behalf of the developer with a VERY long lifespan (like AppVeyor).
I'm assuming that your API provides functionality and/or resources that are associated or owned by an end-user, and you want to allow other application to also access this data on behalf of each end-user. If this isn't the case, and you API is general-purpose and does not require the notion of an end-user identity then other approaches like API keys could also meet your requirements.
Considering the end-user delegation scenario, the approach I would recommend would be going with the creation of separate client applications within Auth0. Like you said, you could automate this process through the Management API so that this process could be handled in a self-service way. Despite being self-service, the application that enabled the registration could still apply constraints in order to make sure only eligible developers could obtain the necessary information to then obtain access tokens to access the API.
This has the benefit that if you wanted to stop an existing developer from using your API you could just remove the associated client application and they wouldn't be allowed to request access tokens anymore and the ones they already had would be short lived and soon expire. This requirement is more complex to implement when using long-lived tokens because they would need to be revoked/blacklisted.
A final note, if these applications don't require to act on behalf an end-user when calling your API and you would prefer to still accept access tokens instead of using a different approach like API keys, then you can consider registering client applications meant to use the client credentials grant.
I'm creating a mobile app for customers that need to access an api that I use.
The api requires authentication and the app needs to call the api to receive some data that is specific to each individual customer(mobile app).
I just want to make sure that the right way to do this is for the mobile app to send the query to my server which will then make the authenticated api call and return the response to the mobile client?
or is it possible to have the mobile make the api calls directly, presumably using the same authorisation key?
This is primarily an opinion-based question, however I'll give it a go:
[paraphrased] Can my server act as an API proxy to make authenticated calls to another API on behalf of my unauthenticated users?
This is a common occurrence in the API world, but some things you need to consider:
It's an extra layer in between the user and the service, which adds time to the data transport. Make sure you build your proxy to be scalable or use a 3rd party service that can manage that on your behalf. Either way, don't forget to factor in cost.
Usually service providers require authentication for a reason. Are you violating any license agreements by opening up their API like this?
Is the authentication per-application, or per-user? If it's per-user (e.g. each user logs in and retrieves a unique access_token) then you're going to be making calls to the back-end API as a user instead of an application.
Is the destination API rate-limited? Instagram's API, for example, only allows 5000 requests per hour. If you have 10,000 users that use it once per hour, you'll have already hit that limit.
Are there security concerns opening up the destination API like this? Is there sensitive information that you need to protect? If so, opening it up like you do are you creating security holes?
Is it possible to have the mobile make API calls directly to the target API, presumably using the same authorization key?
Absolutely this is possible - provided that you follow the authentication flow established by the target API. You'll want to consider the same list of concerns listed above though, in addition to:
If you're using an auth flow like OAuth2, the standard dictates that each user should authenticate as themselves and make API calls using a unique access_token. Does your target API provider offer this service? If so, that's the way to go, that way if an access_token is compromised, only that user's data/account/etc. is at risk.
If you're using app-level authentication (e.g. your app's client_id and client_secret) directly in your mobile app, be warned that it can be obtained and compromised with little effort, and thus an attacker could gain access to the entire target API this way.
I'm in the middle of creating a RESTful API for a personal project and I've been reading about api authentication. It is probable that I just don't understand what different things are for. What is OAuth for? What are API keys for?
Main Question
Why can't I just have every request use HTTPS and use sessions/cookies?
If users will access your API through an application you own or control, then HTTPS and user authentication/authorization is ok.
However, if you want to allow applications created by other developers to access your API OAuth and API keys allow you to control how these third party applications use your APIs.
API keys: By assigning individual api keys to each application, you can identify the application sending the request. You can use this information to track or limit what the application can do with your APIs.
OAuth: If the 3rd party application needs to access sensitive data owned by users or perform an operation on their behalf, then you want to ensure the user is ok with this. One way you can do this is to require the application to pass the user credentials with every request. However, this is usually not a good idea as you don't want users to reveal their usernames and passwords to third parties. Here is where OAuth comes to the rescue as it allows users to provide third parties with limited permissions to access your API on their behalf.
SSL is adequate for this if:
you require a client certificate
the application obtains the client certificate
the application validates it against a list of acceptable clients
the application records which client executed the transaction.
Without all that you're just accepting transactions from just anybody, which is the problem that OAuth is solving.
I have been looking on a lot of questions about REST API and security and found some interesting informations but there is still one thing I don't understand.
So, I have a REST API developped with Zend Framework with basic authentication over an https channel (so if I understoud what I have read, the login/password are encrypted when they are sent).
The purpose of this API is to be called by Android/iPhones apps and will only be available to people who have a login and a password
SO, currently, to call the API, the login and password are always sent with the call and so, I check them at every call (the result is it makes a call to the database just for authentication at each call to the API).
Is there some kind of session management (as in web developpement) to avoid that?
Thank,
REST API should be stateless, but you can use request signing using some secret key you obtain after first submission of username + password.
In other words, do not send username and password every time, just use once, to obtain secret key.
You may take a look at several APIs that sign the requests, eg. some implementing OAuth.
I always wonder how can the Twitter and many social network application provides the API for developer via registered app key. How can it granted and track the using of those external application?
Can you answer me this question? because I alway wondering about this.
Twitter, Facebook, Google Apps, and others often use OAuth to provide this authentication and tracking. There is a lot of information to be found at http://oauth.net/ and you can play around with OAuth in general at Google's OAuth Playground.
Generally speaking the service would generate an API key for you when you sign up for developer access. This key is then associated to your account.
Whenever you make a call to an API, you would be required to pass that key as one of the parameters. That method would then verify that you passed a valid key and would know who was making the call based on the key -> account association created when you signed up.
For Ruby on Rails:
Easy Rails API Authentication Using restful-authentication
http://www.compulsivoco.com/2009/05/rails-api-authentication-using-restful-authentication/