- Home>
- security
In this post, I share my experience about doing OpenID Connect (OIDC) implicit flow using Microsoft Authentication library (MSAL) for Angular, Microsoft Identity Platform (v2.0), and Azure AD. This post is part of the blog post series in which I cover implementing OIDC flows to protect as system that consists of an angular front-end application and asp.net core web apis. In the previous post, I give a high level overview of the technologies involved in protecting such a system.
In this and upcoming blog posts, I’ll be talking about integrating Azure Active Directory (AAD) and leveraging open source libraries to protect a system consisting of an angular application and ASP.NET core web apis.
In this post, I just want to give a high level overview of the setup and the technologies involved in securing such as system. As such, I likely gloss over some of the points. In subsequent posts, I’ll cover the specific parts in more details.
In this post, I am going to share a few things I have learned about JWT token. Specifically, I am going to go over the structure of a JWT and how you can trust the information in the token to be authentic by validating the signature.
In this post, I share three ways of gaining a Windows virtual machine access to a key vault. The machine can be an azure virtual machine or a non-azure machine such as your personal computer or a on premise server.
In this post, I discuss the features of Azure Active Directory B2B (AAD B2B) and Azure Active Directory B2C (AAD B2C), the differences between them and when to use one vs the other.
In this post, I cover the basics, what I have learned about encryption while building a module to protect Personal Identifiable Information (PII) data using the Java Cryptography API (JCA) and Bouncy Castle API.
You may find this post helpful if:
Update: This post shows how to authenticate to azure key vault using app id/secret. However, this approach is less secure than using managed identity for azure resource and certificate for non-azure resource to grant the resource access to the key vault. For production environment, you should definitely consider using azure managed identity or certificate to authenticate and access azure key vault from your resource. Checkout my other post for more details.
In this blog post, I’ll show you the steps on how to keep the credentials out of the source code of an ASP.NET Core app using Azure Key Vault.
If you want some convincing examples why leaving secrets in the source code is bad, check out this post.
I assume you have some familiarity with developing an ASP.NET core 2 app. You also need an Azure subscription to register your application in Azure Active Directory and create an Azure key vault.
Basically the process involves these steps:
Checkout the sample app for this post from my Git repo.
In a XSS attack, the attacker’s goal is to inject a malicious script into the user’s browser and have the browser execute the script. The vulnerability of web applications to XSS attacks is because of not validating user’s input and/or not encoding/sanitizing data when rendering into a browser. Don’t confuse Cross Site Scripting with Cross Site Request Forgery (CSRF).
A successful XSS attack could be devastating. Examples of damages include exposing the victim’s sensitive data, displaying inappropriate/unintended content, involuntarily transferring of money, impersonating the user’s account etc …
XSS attack is listed under the top ten most critical application security risks for 2017.
Several XSS types of attack describe how a malicious script arrives at a user’s browser: stored XSS attacks, reflected XSS attacks, and server vs client XSS attacks.
If you are like me, you might have thought OAuth 2 is for both authentication and authorization. After all, the main OAuth 2 flows ( Authorization Code, Implicit, User Credentials ) all require a resource owner to authenticate against an authorization server. In this post, I’ll talk about some of the reasons I’ve learned why OAuth 2 is not for authentication.