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.
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 have several Web PI endpoints currently secured with an access key. I'm not opposed to abandoning this security model.
Now, we're building a web app that will consume the services. The front end will have a login screen to secure portions of the application. I also want to make the Web API services available for use by applications other than our own (think public API).
How should I secure my services and allow access from our own web UI and as a service?
There are many ways to secure Web API 2.0 endpoints.
It seems like you already secured your endpoint with an access key, no idea how your clients know the access key.
For your web app I would ask:
How is the user logging in as you described? What authority are they providing their credentials to? Can you use that authority to attach a token to the requests of your web service?
You mention you also want to provide a public access through a public api. What credentials will they have? What authority will they request access from? You could set this up many ways with different types of credentials e.g. user name and password/client certificate/access key.
Microsoft has some really good resources about this including:
http://channel9.msdn.com/Shows/Web+Camps+TV/Securing-ASPNET-Web-APIs
http://www.asp.net/web-api/overview/security
I can think of:
HTTP Basic Authentication
OAuth/OpenID Connect
Client and Server Certificates
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?
Since Google lists the ClientLogin API as deprecated what is the recommended alternative?
In my case I need a server to authenticate and post things using credentials which I own. Alternatives like OAuth won't work in this context
The authentication method varies based on the scenario of your application. The scenarios reported by Google documentation are:
Login
Web Server Applications
Client-side Applications
Installed Applications Devices
Service Accounts
In your case, the Web Server Application scenario might be useful (if you give more details about what do you mean for "In my case I need a server to authenticate" I can be more precise about this point).
However, the recommended alternative to ClientLogin is OAuth2.