- Home>
- Angular
Recently, I learned about why implicit flow is not secure because of exposing the access token in the browser. Authorization code grant with PKCE is more secure and should be preferred over implicit flow for protecting a public application which cannot keep the client secret secure. The good new is if you already use oidc-client-js and get tokens from azure ad via implicit flow, the changes you have to make to use authorization code flow with PKCE are minimal. In this post, I show what you need to change to use authorization code grant with PKCE.
A few months ago, I gave an overview of the libraries I use to implement OpenID Connect implicit flow in an angular app, and On-Behalf-Of (OBO) flow in ASP.NET core backend APIs. You can checkout this post for more info. In that post, I talk about the security flow from the angular app to the downstream APIs. The angular app communicates only with a single backend API which acts as a gateway that forwards the requests from to other downstream APIs.
In this post, I go over the details of obtaining an access token via the OBO flow to call protected endpoints from a web API (which I refer to as the gateway in this post) to another web API .
For an angular application, at build time, if you pass in a configuration name, then the webpack build tool replaces the content of the environment.ts file with the content of the environment. For instance, if you run the command ng build --prod
, angular replaces the content of environment.ts with that of the environment.prod.ts. Similarly, if you run ng build --staging
, angular replaces environment.ts with environment.staging.ts, provided the file exists. This approach works but it requires building multiple times for different environments. In this post, I show you the approach I learn from my coworker to build one time and deploy to multiple environments, using angular APP_INITIALIZER and the File Transform task in azure devops.
You can find complete source code for this post on my github.
In my previous post, I mention using MSAL for angular to implement implicit flow in angular application. However, MSAL is still in preview and I could not get it to work in IE 11. In addition, I could not find a way to obtain both access and id tokens in a single call. I have switched to oidc-client-js. Besides adding the polyfills for IE, I did not have to do much for oidc-client-js to run in IE11. The library also allows me to configure response_type parameter of a request to the authorization endpoint to obtain both id and access tokens in one call. Overall, I have found the library to be more stable than MSAL for angular. In this post, I share how I configure oidc-client-js in an angular application to obtain tokens from Azure Active Directory (v1.0 endpoint) as well as some of the lessons I have learned.
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 talk about the Replace Tokens extension, which I have found to be useful for dynamically replace values at build time. For instance, I have used it to display the build number which comes from azure build pipelines in an angular application.
Making the build number readily available to both programmers and non programmers such as business system analysts (BSA) and end users has a couple of benefits. For instance, by displaying the build number in the app, the analysts can quickly tell whether they are testing the expected build after a deployment. As a developer, I often find myself wondering why certain features work on one environment and not the other. Seeing the build number in the app allows me to quickly check whether an issue has to do with the codes or the environment.
Azure Devops provides an easy way to assemble the build number. You can see the options to edit the build number in your build pipelines, under the Options tab.
Sometimes, I have seen developers (myself included) use simple strings to represent dates. This could lead to unexpected behaviors if you are not careful. For instance, I recently ran into a bug where the PDF document the program generated show the incorrect date, which was a few hours off from the correct one. The date value originated from a data API and did not include a timezone. The intended time zone was local time, which is Pacific Standard Time (PST) in this case. However, because we were using storing the date in the angular application using string instead of the javascript built-in Date type, when the framework serialized the data into JSON and sent to .NET, it kept the date as is and did not add any timezone. At the backend, .NET deserialized the value back into a DateTime object, and when we attempted to convert the value to local time usingDateTime.ToLocalTime()
for displaying in the document, we got an incorrect value because .NET assumed the date was in Universal Coordinated Time (UTC).
The bug was because of inconsistencies when passing date values and not including timezone information. However, had we used the frameworks’ built-in types for representing dates instead of strings, we could have avoided the issue.