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.
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 am developing software that will be used on small system at clients. The software is fetching Google calendar events from whatever Google account the client adds to it. The thing is that Googles API requires an secret key to work. As it is now, the system is working but the key is directly in the code, which means that the end user will be able to see it.
Firstly, is this a problem? I guess that because the key is "secret", there will be bad if a client can see it. Second, if this is bad, how should I do to avoid this? Is it even possible?
I should not be a problem since the key alone is not enough to generate an access token. You also need a refresh token or authorization code for that.
One risk is that, using the key, one of your clients (Alice) builds an OAuth authorization URL and tricks another of your client (Bob) into authorizing Alice's custom application to get calendar data. That problem only occurs if you're using the "installed application" workflow with the "urn:ietf:wg:oauth:2.0:oob" redirect URI.
If you want to avoid this problem, you can decide to host a web service that will handle the authorization for the embedded system. This web service will hold the client secret, and will receive call from your systems to either request authorization from a customer or refresh a token. Of course now you need to secure this web service, but you can probably do that with a customer-specific set of credentials. That way the only thing on the customer's premises are his specific credentials to access the webservice, nothing else.
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 am working on an internal authentication system for users of a set of of RESTful web applications. Our intention is that a user should be able to sign-on once via a web form and have appropriate access to all these RESTful applications in our domain, which may be distributed in a private cloud across many servers. (I understand already that having a single authenticated session is not aligned with a pure RESTful approach, but this is a usability requirement.)
The applications themselves will be written in a variety of programming languages so a language-neutral approach is required. It was suggested to me that we might use OpenID or OAuth or a similar framework to handle the authentication but my understanding is that these are intended for third-party services and not the first-party services that would share data on our internal system. In this case, we might have a central provider service with all the other applications treated as third parties (or relying parties).
Questions:
Are OpenID/OAuth suitable for authentication among first-party services?
If so, how would one be advised to set up authentication for this use case?
Wouldn't a user have to grant individual permission to each first-party server that they wanted to use, just as they would need to grant individual permission to any third-party server? I think this would violate the requirement of having a single sign-on for accessing all the first-party services.
Are there good examples of sites supporting this first-party use case?
What would be a good alternative framework for this first-party use case?
You do not need OAuth for SSO services.
The primary use/advantage of OAuth is, as you know already, granting access to a 3rd party app to access/use your resource in a controlled manner.
Rather than having an authentication/authorization server that you would need for OAuth, why not use a single log in service across all your APIs. An OAuth access token is totally different from what you need.
As far as I understand, what you can have is something like OAuth in a way that your server vends out tokens to the app. (I'm assuming that it's a totally internal system, so tokens cannot be misused).
So basically what I'm proposing is:
When an app tries to access the first API it's redirected to a web-form.
The user enters credentials and is taken to the DB for verification. Let there be a service that generates a token for the user/app
Next API access request would be made with that token - the token uniquely identifies the app
Depending on the level of security you need you can sign some text using HMAC and send it as token, or if its totally internal just generate a unique identifier for the app/user and send it to other API
On receiving the token, each service first calls the main server with the token and internally fetches the corresponding customer/user ID and performs the required function.
In short separate the login + token generation + token verification into a different module. All APIs should use this module for login/token verification.
What I have proposed here works like OAuth but all security aspects have been stripped down since you want to use it in a private cloud.
Oauth supports multiple different kinds of flows. You can use the client crendentials flow from Oauth 2.0 to avoid asking the user to grant permission for every app (this is intended for the cases where you control both the server and the app or where you want to preauthorize certain apps). This post does a good job explaining everything: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/
This is a conceptual challenge that I'm trying to wrap my mind around. Let's say I have an SSO (single sign on) service and two separate web services that use it. Let's say that the SSO login happens via OAuth, just like Login with Facebook. (Correct me if I'm wrong that they're not just requesting an OAuth access token for the site in question.)
The question is then, how should the two web services expose their own APIs to third parties? Given that we've drunken the OAuth kool aid, it seems logical that the third parties should be considered OAuth consumers and they should request that the user approves an access token for them. Accepting that the question is, should the the web services handle all this OAuth stuff themselves, having the third parties register as OAuth consumers with them and only using the SSO to login the user? Or, should the web services hand all responsibility off to the SSO service? For signed requests, the web service would check the validity of the access token via the SSO's API and then process it as normal.
I see pluses and minuses to both approaches. On one hand, the first option places fewer demands on the SSO and each web service can handle the authorization for their APIs their own way. On the other hand, having the SSO handle things means that the third parties can get access tokens that are valid across all the services, just like how users can login across all of them.
This can enable a better user experience, as otherwise the third party might have to keep asking the user for authorization as it needs to use different web services of the system, despite the separation between the different web services being invisible to the user. Of course, then either the SSO needs to have some sort of shared permission rules or each web service will still need to enforce its own rules. Also, the SSO would probably have to take some sort of text or HTML from the web services to display when asking the user to authorize the third party service.
Any suggestions? Are there any existing, publicly documented systems that do this well? Am I just over-complicating the whole thing?