Building secure applications using modern authentication (part 4)

This post is a part of a series.

• Part 1 – The basics
• Part 2 – About scopes or permissions and MSAL
• Part 3 – App Gallery and publisher verification
• Part 4 – Additional Security Features (this post)

Additional Security Features

Finally, I just want to share a few additional security features to keep in mind when creating your applications.

• In an effort to abide by the principle of least privilege it is highly recommended to implement RBAC (role based access controls) within your application. You can technically achieve this with either roles or groups, however I prefer roles for the reasons I detailed on my previous blog, Roles vs Groups. Organizations can further restrict the time and expiration of these roles by implementing PIM (Privileged Identity Management).

• Use the Integration Assistant, which is a handy tool to generate specific security recommendations based on the type of application and wether or not it calls APIs.

• A new feature announced recently offers a new secure option to use a federated identity to allow GitHub Actions (only one currently supported) to exchange tokens from GitHub for access tokens in AAD. These tokens then allow access to Azure resources without having to worry about using secrets or certificates. I think about these as external managed identities, for GitHub only (for now).

I hope this series of posts is helpful as you embark to create your own secure applications! I will do my best to keep these pages updated as more security features become available.