We have a few different options for authentication based on how the client is setup, and basic authentication is the fall through if the others do not work. We'd like to ensure we cover all of our scenarios before that date. How can we set up an environment for testing with the coming changes?
Related
I've read a lot of articles on this subject and they all suggest completely different things that I can't yet structure in my head.
I have one backend app (spring-boot + kotlin). I have nginx and one android (kotlin) mobile app uses backend api and of course Postgres. By the way backend app and postgres are packages in docker containers via docker-compose.
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
For example:
Spring-security: a huge thing that you don't know what to do with, most likely you can use it to solve your problems, but it's overkill. But if you decide to use spring-security, this will help you {...}
...
By the way, I'm not against spring-security, I just really think it's too much for my task. But I'd be happy to hear your opinion.
Your Problem
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
You have in hands a very hard task to complete. While not impossible it's very hard to accomplish with code written on your own or by trying to leverage security features on your framework of choice.
To understand why it's so hard you first need to understand the difference between who is in the request versus what is doing the request.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
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.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
After you understand this idea and it's ingrained in your mindset, you will look into mobile API security with another perspective, and you will be able to see attack surfaces that you never though they could exist.
Possible Solution
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
The best approach to solve your problem is to go with a Mobile App Attestation solution suggested in the answer I linked. A Mobile App Attestation needs to be able to work in tandem with your mobile app and backend in order for the backend to have a very high degree of confidence that what is making the request is indeed a genuine version of your mobile app, that hasn't been tampered with statically or at runtime, and it's not under a
MitM Attack
The Manipulator-in-the middle attack (MITM) intercepts a communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.
The MITM attack is very effective because of the nature of the http protocol and data transfer which are all ASCII based. In this way, it’s possible to view and interview within the http protocol and also in the data transferred. So, for example, it’s possible to capture a session cookie reading the http header, but it’s also possible to change an amount of money transaction inside the application context
Be aware that solutions to solve your problem that are specific to the backend or to the mobile app will not be able to achieve a very high degree of confidence in securing your API backend from serving requests not originated from your genuine mobile app, but it's better to have them then nothing.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
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.
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.
The easiest way probably is to define a shared secret on the phone and the backend service.
On the mobile phone, with each request, you send the secret, e.g., as an HTTP header.
On the backend, you need to implement a Filter (e.g., OncePerRequestFilter) that checks the request for the secret and compares it to the value stored in the backend.
I'm using Python and Plaid's development environment to download bank balances and transactions. To get the initial access tokens, I'm launching Link from quickstart, and can do that in standard and update mode.
The problem I'm running into is how frequently my API call returns the ITEM_LOGIN_REQUIRED error and I have to re-authenticate. For a Regions account I've been testing, this happens a few times throughout the day. For a Pinnacle Financial Partners bank, this happens almost immediately after updating the access token. As in, I can log in through link, successfully fire an auth/get request, and by the time I can send another request (e.g., balance/get), I'm already getting ITEM_LOGIN_REQUIRED again.
As I'm evaluating Plaid for production use, is this frequent authentication atypical? Is it a known limitation with development, or with specific banks even on production? I've seen some banks (Bank of America) only work in production, but I'm hoping what I'm experiencing is just the nature of working in development. Thanks.
Development vs. Production environments are virtually identical and shouldn't impact how often you hit ITEM_LOGIN_REQUIRED.
What you're seeing is atypical, though. Unless you have multi-factor auth turned on and configured not to trust known devices, this shouldn't happen.
Assuming you don't have that configured, would you mind submitting a support ticket so Plaid Support can look into this and help figure out why it's happening?
My enterprise application is developed in .net framework 4.5 and is using windows authentication. In which case, as we all understand, it is the underlying AD(active directory) that authenticates the user.
I have to replace windows authentication with token based authentication, keeping the .net framework 4.6 and AD(active directory). I guess oAuth is a possible solution, could you please share some thoughts on other possible solutions and as how could I get started.
HISTORY
It was common some years ago for apps to be developed for a corporate intranet, in which case Windows Authentication was a good solution. When token based authentication came along the benefits typically were:
Extend reach so that apps could be used over the internet
Support cross domain scenarios, eg APIs in a different domain
Support multiple authentication methods / policies depending on user location and device type
Write less security code and make new security features available to multiple apps
IMPLEMENTATION
An OAuth migration is a major architectural change and needs to be managed in terms of costs and benefits, though once done your apps will be quite cutting edge. Here is how Windows Authentication typically works in an OAuth 2.0 / Open Id Connect world, which requires a more complex setup:
Your UI redirects to a Cloud Authorization Server (AS), such as Azure Access Control
The AS redirects to an identity provider - such as an on premise version of ADFS (Active Directory Federation Services) - that is configured to use Windows authentication
When in the corporate intranet the user is automatically signed in and ADFS posts tokens to the AS
The AS posts different tokens to your UI
Your UI calls the API with the AS token and the API validates it
GETTING STARTED
If you decide that the effort is worthwhile then there are 2 parts to the job. Note that your application code will only ever interact with the AS and doesn't need to know or care about the authentication method:
Infrastructure migration
Updating the code in your UIs and APIs
If it helps, my blog and code samples are designed to help people deal with some of the challenges of OAuth tech. Maybe have a look at my first tutorial to get set up.
While prototyping out an API & SDK, I've run into this question with several plausible solutions. I'm looking for help with some of the high level architecture. In short, it is guaranteed that some consuming applications of the API are going to want to configure their own authentication providers.
Options that I've been munching on:
Keep resource server and authorization coupled but figure out some way to delegate authentication in one of the authentication providers in my auth manager to the client application.
This sounds promising until I realized that in the particular use case, it's actually necessary that even my providing application not know the user's credentials.
Separate the resource server and make each consuming application responsible for providing an authorization server, and set those endpoints as part of the configuration when registering the consuming app with the resource provider.
This feels like an uncomfortable inversion of what is often desired when using authorization_code grant types. It also would require any "default" authorization providers to be implemented by each consuming application.
Some kind of delegating authorization server that falls back to a default if a client hasn't provided endpoints for their own authorization server.
This would probably be a good solution, but I'm not sure how to do it the "spring-security-oauth2" way or if I'd have to implement a bunch of my own stuff.
Create a default auth server, and optionally allow consuming applications to point to whichever auth server they want.
This seems viable approach in that it offers lots of customization. My concern is, how do I enforce some kind of registry with the resource server? If the auth server is the server that approves consuming applications, but I don't want to let any consuming application implement its own auth server, just some of them. Otherwise non-trusted clients could end up approving themselves!?
In case this influences any guidance, my resource provider will need a fully inflated OAuth2Authentication object (which contains user details and client details).
This image mostly explains what I'm talking about, except I want multiple authorization servers and want to leave it to the consuming application to decide which authorization server to point at. How could I check on the resource-server side of things that the authorization server proxying the requests is an approved authorization server?
ADDENDUM:
I took a look at the existing implementation that's being used for this custom authentication case and I guess we're just reading a token off their session that gets set by their own login service and building their user each time off of that. This sort of customization is a problem in that we're removing customizations from the provider side of things in favor of handling that in the consuming applications. So, I'm looking for solutions so consuming apps can define their own authentication means, to the point of even providing users that the providing application doesn't persist (which leads me to think it may need to be an entire auth server).
That being said, this seems like a potentially unsustainable inverted model (IMHO, the provider should be the maintainer of users and authorization, not the consuming apps). So, I'll probably recommend a more business oriented change.
I believe I have finally come up with a secure and maintainable way of solving this.
Let consuming applications optionally register an authentication callback with the authorization server.
Require incoming authorization requests from that application to the authorization server on behalf of a user to include a token, that token should be stored by the consuming application as a means of referencing whichever user is actively causing the API call.
When an authorization code request is received by the authorization server from an application that has registered one of these callbacks, then POST to that application's registered authentication callback and include the token that was provided by the consuming application in the request.
The consuming application should take the token that was POSTed to it's registered authentication callback and look up the corresponding user, and return a response containing the full user object on whose behalf the providing application should operate (or some kind of error code if the token is invalid).
The authorization server should then generate an authorization code and return to the callback uri submitted with the authorization code request. This means we're back on track according to step 4 in the diagram in the original question. The remaining steps can be carried out as-is.
There is a remaining question of how this might be implemented to take advantage of as much of the spring-security-oauth2 framework as possible while still achieving this extension.
So I've been tasked to develop some enterprise web applications, but our users hate logging in to every site. After our users authenticate to eDirectory, is it possible to provide a Single Sign On feature for them. I know it's possible to do with AD, but I was wondering if anyone has actually done it with Novell?
Currently, I'm testing out solutions on WAMP (Apache 2.2). I was looking into mod_auth_sspi but I'm not sure if it will work with Novell.
The typical issue on these setups is how you are going to pass credentials from the Browser to the Web Application. You can setup Kerberos on eDirectory which should work similar to Microsoft Active Directory using GSSAPI which is vendor independent.
You may need to make some changes to browser settings to make any of these work seamlessly.
However, SPPI is a proprietary variant of GSSAPI with extensions and very Windows-specific data types and AFIK, will not work easily with eDirectory or browsers other than IE.
If possible, look into a Access Manager product that will be (at least nearly) seamless. Most will allow any(?) WEB based application to utilize SSO in one form or another.
-jim