<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Authentication :: Airlock Microgateway</title>
    <link>https://docs.airlock.com/microgateway/5.2/configuration-guides/authentication/</link>
    <description>This chapter contains configuration guides for authentication.</description>
    <generator>Hugo</generator>
    <language>en-US</language>
    <atom:link href="https://docs.airlock.com/microgateway/5.2/configuration-guides/authentication/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>JWT Authentication</title>
      <link>https://docs.airlock.com/microgateway/5.2/configuration-guides/authentication/jwt-authentication/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.airlock.com/microgateway/5.2/configuration-guides/authentication/jwt-authentication/</guid>
      <description>This guide shows how to enforce client authentication with JSON Web Tokens (JWTs) in Airlock Microgateway. Microgateway retrieves a JWT from the request, validates it using the configured JWKS and JWT settings, and then applies access control rules (optionally including claim checks).&#xA;JWT authentication is configured by connecting these resources:&#xA;JWKS: provides the public keys used to verify the JWT signature (either from a local Secret or a remote JWKS endpoint). JWT: defines where the token is extracted from and what makes a token acceptable (JWKS, issuer, audiences, subject, lifetime constraints). AccessControlPolicy: attaches to an HTTPRoute, enforces JWT authentication via authentication.jwt.jwtRef, and optionally authorizes requests based on JWT claims. Prerequisites A Gateway Deployment. An HTTPRoute routing traffic to your application/API (JWT authentication is attached via AccessControlPolicy.spec.targetRefs[].HTTPRoute). A JWT issuer that provides tokens and exposes signing keys (e.g., via a JWKS endpoint), or signing keys available as a local JWKS file. Configuration Create a JWKS resource Create a JWKS CR that provides the keys used to verify JWT signatures. You can source JWKS either:</description>
    </item>
    <item>
      <title>OIDC Authentication</title>
      <link>https://docs.airlock.com/microgateway/5.2/configuration-guides/authentication/oidc-authentication/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.airlock.com/microgateway/5.2/configuration-guides/authentication/oidc-authentication/</guid>
      <description>This guide shows how to enforce authentication with Airlock Microgateway to allow access only to authenticated and authorized users. Access is granted based on access policies evaluating the claims in the ID token provided by an external OIDC provider.&#xA;The configuration steps below show how to configure authentication enforcement with OIDC to protect a web application. The examples are based on a Microsoft Entra ID integration and must be adjusted to your setup.</description>
    </item>
    <item>
      <title>OIDC Step-up Authentication</title>
      <link>https://docs.airlock.com/microgateway/5.2/configuration-guides/authentication/oidc-step-up-authentication/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.airlock.com/microgateway/5.2/configuration-guides/authentication/oidc-step-up-authentication/</guid>
      <description>This guide shows how to enforce step-up authentication using OpenID Connect (OIDC) with Airlock Microgateway. Step-up is a general authentication concept: it raises the required authentication strength for selected actions or paths. Airlock Microgateway currently supports interactive authentication via OIDC, so this article describes how to implement step-up requirements based on OIDC authentication results (e.g., required scopes and ACR values).&#xA;The configuration steps below show how to extend the OIDC authentication setup with step-up requirements for selected subpaths. Configure OIDC authentication first as described in OIDC authentication, then add step-up rules in the access control policy for the paths that require stronger authentication (e.g., additional scopes or ACR values).</description>
    </item>
  </channel>
</rss>