I'm developing a RESTful API for my app on GAE python and right now I'm trying to figure out the best way to secure this API.
I have my own member/authentication mechanism on this app.
what is the best way to do this?
having public/private key pairs
becoming an OAuth provider
HTTP authentication (seems very weak to me)
other??
First, discard HTTP Auth. It is not recommended in a true REST API since it resides on cookies.
I would go with OAuth. There's a library called appengine_oauth_provider, which could helps you to start implementing your own provider.
You can use Google Service Account for User Authentication. However, people still can register an account and use your API and surely your app engine bill will go up. They've just introduce Google Cloud Endpoints at Google I/O 2012. You will have a Client ID which will only use on your client application(Android,iOS).
Google I/O 2012 - Building Android Applications that Use Web APIs with Yaniv Inbar and Sriram Saroop
Google I/O 2012 - Building Mobile App Engine Backends for Android, iOS and the Web
If you are interested in, you should try to sign up for trusted tester at
http://endpoints-trusted-tester.appspot.com/
Related
I am developing a webapp to access data in Bigtable in Vue and hosting it on Firebase Hosting and I am using Firebase Authentication to control user access for the app. I am curious as to best practices for authentication and security when it comes to such a use case.
I've read this:
https://cloud.google.com/docs/authentication/end-user
https://cloud.google.com/bigtable/docs/authentication
Here is my question:
I was taught once that the reason we build APIs in front of SQL servers for example was because we didn't want to expose the SQL server directly to the end user and risk bad things happening. So the API sits in between to act as a layer of protection.
In the Bigtable world, Google has provided their client SDKs for Bigtable that interacts with Google APIs but it has also suggested to use service account json files in most use cases. Wouldn't this be dangerous since the service account credentials then allows anybody who somehow finds it in the app files to do read or write to Bigtable and potentially mess up the database?
Should I build an API in front of Bigtable and use Firebase Auth to check if the client is authenticated using JWT before allowing operations? Or is there some other best practice?
Also,
https://cloud.google.com/docs/authentication/end-user
This article suggests that I use OAuth, so can it be linked to Firebase Authentication somehow?
Thank you!
I am planning to code a vue web app that accesses backend through API. The web app its self has a front end and a backend that requires login. I intend to grant api access to the web app, an android app and ios app. Question is, how do i grant backend permission to specific apps on different platforms without using oAuth, authO or Okta. Can JWT work in such cases?
JWT FOR AUTHENTICATION
Question is, how do i grant backend permission to specific apps on different platforms without using oAuth, authO or Okta.
Auth0 and Okta are authentication providers that use OAuth2 and/or OpenID Connect standards to Authenticate users, and the resulting token is a JWT, more precisely a signed JWT, that is known by JWS:
A JSON Web Signature (abbreviated JWS) is an IETF-proposed standard (RFC 7515) for signing arbitrary data.
This is used as the basis for a variety of web-based technologies including JSON Web Token.
Can JWT work in such cases?
Yes, you just need to find the correct packages to use in your API server and frontend.
To bear in mind that user Authentication only identifies Who is in the request, not What is doing the request, and in my experience I see that this is a common misconception among developers, no matter if juniors or seniors.
The Difference Between Who and What is Accessing your API Server
I have written a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? I go in more detail about the difference between Who and What is accessing your API server:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
I hope that after reading it you are now conscious that the Who is the user your API server will be able to Authenticate and Authorize access to the data, and that the What is the software making that request in behalf of the user.
LOCKING THE API SERVER TO SPECIFIC APPS
I intend to grant api access to the web app, an android app and ios app. Question is, how do i grant backend permission to specific apps on different platforms without using oAuth, authO or Okta.
Well you bought yourself a hard problem to solve, but we developers love challenges, don't we ;)
While user authentication may let the API server know Who is using the API, it cannot guarantee that the requests have originated from What you expect, the original version of your mobile app or web app, and for your surprise you may end up discovering that sometimes your own legit users may try to bypass your services and use repackaged versions of your mobile app or automated scripts to have access to features or benefits they wouldn't have otherwise.
To defend your API server you need to apply defense in depth with as many layers as you can afford(just like was done in castles in the past centuries) and may be required by law or specific market regulations.
For web apps
In the context of a web app you may want to follow my advice on this answer to the question secure api data from calls out of the app, specifically the section entitled DEFENDING THE API SERVER.
For mobile apps
For mobile apps, the API server can have more confidence in What is making the request when the concept of Mobile App Attestation is being used, and you can read this answer I gave to the question How to secure an API REST for mobile app? to have more detail. You will be looking to read specifically the section Securing the API Server and the section A Possible Better Solution.
DO YOU WANT TO GO THE EXTRA MILE?
In any reply I gave to a security question I always like to reference the excellent work from the OWASP foundation, that can help you strength the secuirty of your application and servers.
For Web Apps
OWASP Web Top 10 Risks
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
I’d like to use the Google Cloud App Engine to serve a SPA and a REST API, both secured behind an authentication wall.
Is there any recommended way of doing this?
So far, I’ve found tutorials on how to secure an API, but not an SPA. Both ends are served from different projects, but I’d like to have a unique authentication step.
Typical flow would be:
Before serving the SPA source code, ask for authentication
Once authenticated, serve the SPA and allow the SPA to access the API resources
Thank you!
So far I’ve reviewed the documentation, it doesn't seem like there is any specific recommended way to authenticate an SPA within Google Cloud.
However, I think a pretty secure way would be to authenticate your application using the Toolkit Identity API of Google. The procedure would be to call this API from App Engine as the first necessary requirement.
This method works with Oauth2 access tokens. I think you could request for authentication credentials to your users before launching your application and granting access to the other resources/APIs.
I'm developing a web API that will be called by other web apps in the same Azure host and also other 3rd party services/ app. I'm currently looking into API Apps and API management, but there are several things unclear for me regarding security implementation:
Does API App need to have authentication when implemented with API management? If yes, what are the options? This link http://www.kefalidis.me/2015/06/taking-advantage-of-api-management-for-api-apps/ mentions "Keep in mind that it’s not necessary to have authentication on the API App, as you can enable authentication on API Management and let it handle all the details." So that means having the API App authentication to public anonymous? But then someone who knows the direct URL of the API App can access it directly.
What is the best way to implement API Management security? The one mentioned in the tutorial (Having a raw subscription key passed in the header) seems to be prone to man in the middle attack
What advantages does API App add instead of implementing with normal Web API project?
Thanks in advance.
I can answer from API Management perspective. To secure the connection between API Mgmt and your backend (sometimes called last-mile security), there are a few options:
Basic Authentication: this is the simplest solution
Mutual certificate authentication: https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/ - this is the most common approach.
IP Whitelisting: if you have a Standard or Premium tier APIM instance, the IP address of the proxy will remain constant. Thus you can configure firewall rules to block unknown IP addresses.
JWT token: if your backend has the capability to validate JWT tokens, you can block any callers without a valid JWT.
This video might also be helpful: https://channel9.msdn.com/Blogs/AzureApiMgmt/Last-mile-Security
I think the document meant you can do the JWT token validation in APIM. However, to prevent someone calling your backend directly, you'll have to implement one of the options mentioned above in your Api Apps
I have hosted a web service on App engine cloud endpoint. The APIs are protected by Auth2.0 as google say but for google accounts.
What I want to achieve is allow these APIs to be accessed using 3rd party tokens. Lets say I have my on Authentication server also providing User Management. I want my google endpoint APIs to be access based on the 3rd party token I provide at the time of API call.
Is this possible?
If Yes, Where should I write the mechanism to verify the clients authenticity and hint of how its to be done.
Also is there any demo project available that provides user management and authentication server and returns a token that can be accepted by App Engine.
Yes
On your app engine project, create the authentication mechanism to validate clients.
As such, there is no single solution available for User management, Authentication Server and Token Issuance, but separate modules are easily available.