Just writing down my list of things that are problematic with TF. While you don’t have agree, it’s good to put the list down and begin that conversation.
The importance of data security has not been left off anyone’s radar. And, in the wake of unauthorized access to the US Capitol building the approach for some is to wipe everything. Potentially malicious attackers on premise, able to access user data and user sessions left unlocked. The historical lack of sufficient technical experts in leading government areas have left reasonable controls out of the picture. The lack of attention to data security in some of the most critical areas results from a number of antiquated mindsets and overall deficit in talent.
However, many companies also find themselves, while not in possession of highly classified and confidential materials, equally sensitive and vulnerable to unauthorized access. Security experts will point to increased availability of cloud solutions with a bifurcation of security responsibility “Of the Cloud” and “In the Cloud”. Cloud usage helps, that’s no longer a question, but it’s only the beginning of the story. As an organization you are in control of your data, your security, and possible remediation strategies when there is a critical incident. But how will you help your users tackle these issues when something happens to them outside of your control? …
Being in a leadership position for a while now there are a couple of things that I can help point to. While there is some good advice in this post which could help, I first want to focus on the misconceptions:
Applications that provide first class APIs require more than simple authentication, they require api keys. API keys generated by your users allow their programmatic services to interact with your apis. These must be generated in a safe way and have different requirements than UI tokens.
In most cases with authentication, you’ll have JWTs to identify and authorize a user. These JWTs are coming from your authentication provider. Internally, you may also have api keys to authenticate your internal services from one to another. However having to authenticate users and service client differently causes issues:
Authentication more frequently works as identity aggregation. This means that it provides a central point to combine any number of user identity management or federated login providers in a single place. For example Google and Facebook login. Providing a solution that works with just one is easy, but to support both and then normalize the data, this becomes more complex.
Providers such as Authress normalize these providing standard OIDC complaint JWTs which includes secure session management.
In this guide we’ll use Google login as an example of how to connect. Setting up authentication requires the following parts:
Securing a web application or api requires actually validating the access token that is being used. When using JSON web tokens (JWTs), there are two mechanisms for doing this. But the core of the solution requires inspecting that JWT, understanding who the authority is, and using that authority for verification.
The properties or fields in a JWT are called claims. JWTs contain an ISS claim. This is the Issuer. The issuer is the authorization server (AS) which is marked by the issuer. As such the AS provides a full document about how JWTs are constructed and how to verify them. This document must always be found at https://${Issuer}/.well-known/openid-configuration (according to RFC 8414). …
Implementing data security within application can be done with various access control strategies. The access control determines if a given user is allowed to perform a particular action on a requested resource. Do they have access to see the data, make updates, or delete it? The answer to that lies within your access control policies. There are different ways to implement security each with its own benefits and detractors. Finding the right one for your application can be the difference between happy users with secure, private data, and a disastrous data breach.
Depending on the types of applications or services your product has, different models may be more or less viable. Below I’ll discuss the prominent types as well as their benefits and detractors. For each of these it helps to have a concrete situation in mind. While it may not completely mirror your use case, an example better shows the difference. …
You’ve just hired a new junior engineer, and of course, want them to be as successful as possible as quickly as possible.
To get this done, create the right environment for them. This is 100% the most important activity you can be doing. It may seem obvious, but no one showing up on day one or day 1000 will be able to deliver efficiently or effectively in the wrong environment.
What this means specifically:
Multitenancy is the concept that your application serves distinct non-overlapping accounts, with resources assigned to and belonging to each account. A simple example of this is an off-line console video game. Each game copy is bought and paid for by a single owner (“account”), and in that copy there may be some amount of gameplay saved data, development data, and user configuration which is unique and sequestered to that copy. In some cases that data may need to be synced with other copies that the user owns. …
Selecting the right response to API requests helps secure your application. While it may not seem so on the outside, every unnecessary piece of information makes it easier for an attacker to understand how to gain access. And on the flip side every piece of missing information makes it harder for a consumer of your API to understand the response to an HTTP request.
Here we’ll break down the most common HTTP error responses used for the purposes of API security. When a request is successful, that means that:
About