Should I specify JWT audience and issuer if I have only one SPA client?



  • I have an API server (ASP.NET Core 5) and SPA client (ASP.NET Blazor). Nothing else: no external oauth servers, identity providers and whatnot

    To secure access, the server issues and validates access tokens (JWTs) and refresh tokens.

    A JWT typically has "audience" and "issuer" claims. Every tutorial and reference implementation seems to specify them, even for a simple use case like mine.

    In my use case I assume the server is both issuer and audience. Is there any benefit to include these claims in my JWTs?



  • This answer complements the comments on the original question.

    What do these claims mean anyway?

    https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1 : The iss-claim corresponds to the authority who issued the token. In federated identity environments this grants information about

    • who signed the token;
    • and subsequently where the validating party should validate the signature;

    For instance, the issuer claim of a token issued by Azure AD typically looks somewhat like this: https://sts.windows.net/{TENANT}.

    In a scenario with multiple possible identity providers this information is crucial to tell them apart and determine towards where the resource owner has authenticated himself to access the resource.

    https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3 : The audience is the intended recipient of the token. This information is required to ensure a token issued to access some-resource.com is not accepted as valid when offered to some-other-resource.com.

    Do we need them in the specified scenario?

    In theory, yes; in practice, probably not. As long as tokens are signed and you possess exclusive knowledge about your signing key, including these claims offers little to no benefit (to reiterate: only as long you serve but a single audience).

    What would this look like in ASP.NET?

    When sticking to the libraries and extensions offered by Microsoft, configuring the setting and validation of these claims is a matter of just a few lines:

    Setting the claims:

    new SecurityTokenDescriptor
    {
        Issuer = "https://my-resource.com",
        Audience = "https://my-resource.com",
        /*...*/
    };
    

    Validating them:

    new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidIssuer = "https://my-resource.com",
        ValidateAudience = true,
        ValidAudience = "https://my-resource.com",
        /*...*/
    };
    

    Note that this checks for the string value only, for calling the token validation endpoints of third party providers further configuration of the authentication middleware is required.

    Comment on the mentioned tutorials

    Every tutorial and reference implementation seems to specify them, even for a simple use case like mine.

    I made this observation too and am rather surprised that these samples gain so much traction. A lot of them seem to forget the main point of asymmetric encryption of issued tokens is to circumvent the issue of storing and providing secrets amongst multiple partially untrusted parties, which is not the case in the given scenario. My advice: go for JWK and symmetrically encrypt your tokens, ideally on top of signing. Third parties won't have a about the user specific claim you issue and can't make assumptions about your API from the intel given in your token (though your security naturally shouldn't rely on that).




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2