Code samples for a series of articles about implementing Transparent Auth Gateway:

1. Needs and means. Requirements for enterprise apps and available off-the-shelf solutions.
2. Auth Flows. Relevant authentication/authorisation flows (OAuth2, OIDC) with sequence diagrams.
3. Writing the code in C#. Comments to the code in this repo – a Transparent Auth Gateway in .NET.
4. Deploying to Azure. App Registrations and Firewall settings (Azure WAF / Front Door).

Transparent Auth Gateway for Enterprise apps

A trusted authority for our enterprise application(s) that

• transparently (without additional user interaction) confirms the identity with the linked Identity Provider (an Azure AD tenant in this case), supporting SSO;
• conducts extra authentication checks (with a potential for own user management);
• issues an access token with app-specific attributes (user’s roles/groups/etc.);
• is self-hosted without reliance on third-party services.

The code uses Azure AD as the linked Identity Provider (for the identity checks) and its own bespoke authorisation server.

The implemented protocols:

• OAuth 2 Authorisation Code Flow (RFC 6749) with Proof Key for Code Exchange (RFC 7636)
• OpenID Connect (OIDC).

Code structure

There are 3 projects:

• AzureADAuthClient – a quick way to ensure that Azure AD authentication is configured. Uses Swagger UI to acquire a token and the standard Microsoft.Identity way to validate the token on WebAPI.
• OpenIdDict.Server – a bespoke Transparent Auth Gateway to confirm the user's identity from the linked provider and authorise the user (issue own access token) according to the bespoke rules:
  • implements OAuth 2 Authorization Code Flow with PKCE to serve other client apps as the trusted authority;
  • perform authentication from the linked Identity Provider (a specified tenant of Azure AD).
• OpenIdDict.Client.Api – A Web API app that validates the access token issued by the Auth Gateway (OpenIdDict.Server). Contains:
  • Swagger front-end to request the token and run HTTP requests;
  • test API end-points.

How's it different?

The key differences:

• Issues its own access token based on internal rules and confirmed user's identity from an Azure AD tenant.
• Requires no database.
• Has minimum code and "magical" behaviour from the packages.