I am developing an App for iphone,android using PhoneGap for the client side. On the server side, i have a Restful API with Sinatra/Ruby(Not Rails). The App is free and anyone can access the services but i need to make sure the minimal level of security is implemented so my API is available 24/7.
I heard about oAuth but i am not sure if that is the way to go.
oAuth is a standard for authorization across different authorization domains (e.g. between services) and is probably not what you want.
The easiest way to secure a REST API is the usage of HTTPS. To secure Sinatra have a look at How to make Sinatra work over HTTPS/SSL?
Related
Largely, what I am trying to accomplish is explained in this video by Azure, which is the unsecured version of adding API keys to a REST API (specifically http://conferenceapi.azurewebsites.net/?format=json).
If you watch through the video, it seems great until you realize that anyone can call the "conferenceapi" as long as they know the url, essentially bypassing the entire purpose of Azure API Management which is controlling/metering peoples' access to an API.
My question is, if I'm trying to create the backend (so Spring Boot controllers) of my API Management service, what am I supposed to do in order to make sure that my REST api is only responding to requests made by API Management?
There is surprisingly little documentation on this that I could find:
Securing Backend Services behind Azure API Management
X.509 Authentication
How to secure back-end services using client certificate authentication in Azure API Management (literally only talks about how to upload a certificate and nothing about backend)
Like, a certificate sounds like a great idea. Only, how do I create the certificate, and how do I verify the certificate from a Spring Boot Application? Azure documentation feels so sparse, unless I didn't find the documentation that would address those questions.
We're getting ready to rewrite an old native windows mobile application that accesses data through a VPN. We'd like the new version (.NET Windows 10 mobile application) to access data through web services that are protected by Okta. What is the best way to do this?
Thanks!
The best way to do this depends on how the web services are protected.
The main thing to keep in mind is that you don't want to store any secrets on the mobile application.
In an ideal world, these web services would be secured with something like OpenID Connect (OIDC), allowing you to authenticate against Okta (the "IDP") to get access to the web services (the "Relying Parties").
However, the real world is messy, where some web services are protected via SAML, OIDC, OAuth, custom headers, etc.
Without knowing more about your setup, my recommendation would be to build against OIDC, using a proxy server (or "API Gateway") as needed to secure your web services using OIDC.
One of my co-workers at Okta has written a sample iOS application in Xamarin that implements OIDC, I suggest taking a look at the ViewController.cs file in that repository.
I am setting up an API for a mobile app (and down the line a website). I want to use oAuth 2.0 for authentication of the mobile client. To optimize my server setup, I wanted to setup an oAuth server (Lumen) separate from the API server (Laravel). Also, my db also lives on its own separate server.
My question is, if using separate servers and a package like lucadegasperi/oauth2-server-laravel do I need to have the package running on both server?
I am assuming this would be the case because the oAuth server will handle all of the authentication to get the access token and refresh access token functions. But then the API server will need to check the access token on protected endpoints.
Am I correct with the above assumptions? I have read so many different people recommending the oAuth server be separate from the API server, but I can't find any tutorials about how the multi-server dynamic works.
BONUS: I am migrating my DB from my API server, so I would assume I would need the oAuth packages migrations to be run from the API server also. Correct?
I have developed a web app that does its own user authentication and session management. I keep some data in Elasticsearch and now want to access it with Kibana.
Elasticsearch offers a RESTful web API without any authentication and Kibana is a purely browser side Javascript application that accesses Elasticsearch by direct AJAX calls. That is, there is no "Kibana server", just static HTML and Javascript.
My question is: How do I best implement common user sign on between the existing web app and Elasticsearch?
I am interested in specific Elasticsearch/Kibana solutions, but also in generic designs for single sign on to web apps and the external web APIs they use.
It seems the recommended way to secure Elasticsearch/Kibana is to have an Apache or Nginx reverse proxy in front that does SSL termination and user authentication (Basic auth). However, this doesn't play too well with the HTML form user authentication in my existing web app. Ideally I would like the user to sign on using the web app, and then be allowed direct access to the Elasticsearch API as well.
Solutions I've thought of so far:
Proxy everything in the web app: Have all calls go to the web app (server) which does the authentication, and have the web app issue the same request to the Elasticsearch web API and forward the response back to the browser.
Have the web app (server) store session info that Apache or Nginx somehow can look up and use to authorize access to the reverse proxy.
Ditch web app sign on and use basic auth for everything.
Note that this is a single installation, so I don't really need any federated SSO solutions.
My feeling is that the proxy within web app (#1) is a common generic solution, but it seems a bit heavyweight to have everything pass through the possibly slow web app, considering that Kibana uses the Elasticsearch API directly.
I haven't found an out of the box solution designed for the proxy authentication setup (#2). My idea is to have the web app store session info in memcache or the like and use some facility in the web server (Apache or Nginx) to look up the session based on a cookie and allow proxy access if authenticated.
The issue seems similar to serving static files directly using the web server (Apache or Nginx) while authenticating using a slow web app. Recommendations I've found for that are however very specific to that issue, like X-Sendfile.
You could use a sessionToken. This is a quite generic solution. Let me explain this. When the user logs in, you store a random string an pass him back to him. Each time the user tries to interact with your api you ask for the session Token you gave him. If it matches, you provide the service he is asking for, else, you just ignore his call. You should make session token expire in a certain interval of time and make a new one each time the user logs back in.
Hope this helps you.
I'm developing Spring REST application for Android & iOS Clients. And there is a web client as well. I can use spring security to implement web client. But for android and ios app should I still use spring security? or is it better to implement OAuth? Since I'm not allowing my APIs to access 3rd party, is it really worth to implement OAuth? cz I myself develop Android & iOS clients.
The main purpose of OAuth is to enable clients to access resources on behalf of 3rd parties, without revealing 3rd party credentials to the clients. In your case you have complete control over your users both at client side (Android/web/iOS) and resource side (the Spring REST application), therefore you wouldn't benefit from the main concept behind OAuth.
Unless you have requirements which prevent you from storing passwords at your clients, or unless you plan to be expanding usage of your APIs to other applications which shouldn't be able to obtain credentials of your users, you will be fine with using SSL/TLS + e.g. HTTP-Basic authentication and spend the saved time on making the application itself better.
Of course you must make sure to never send the credentials over an unecrypted channel, but the same applies to OAuth Bearer tokens.