anchor.diff:  }
   ----
   
  +Let's explore the content of this document in more detail to understand how the claims will affect our application security.
  +
  +.JwtClaims.json claims document
  +[source, json, linenums, highlight="2,6,10,14"]
  +----
  +{
  +    "iss": "https://quarkus.io/using-jwt-rbac", <1>
  +    "jti": "a-123",
  +    "sub": "jdoe-using-jwt-rbac",
  +    "upn": "jdoe@quarkus.io", <2>
  +    "preferred_username": "jdoe",
  +    "aud": "using-jwt-rbac",
  +    "birthdate": "2001-07-13",
  +    "roleMappings": { <3>
  +        "group1": "Group1MappedRole",
  +        "group2": "Group2MappedRole"
  +    },
  +    "groups": [ <4>
  +        "Echoer",
  +        "Tester",
  +        "Subscriber",
  +        "group2"
  +    ]
  +}
  +----
  +<1> The `iss` claim is the issuer of the JWT. This needs to match the server side `mp.jwt.verify.issuer`
  +in order for the token to be accepted as valid.
  +<2> The `upn` claim is defined by the {mp-jwt} spec as preferred claim to use for the
  +`Principal` seen via the container security APIs.
  +<3> The `roleMappings` claim can be used to map from a role defined in the `groups` claim
  +to an application level role defined in a `@RolesAllowed` annotation. We won't use this
  +feature in this quickstart, but it can be useful when the IDM providing the token has
  +roles that do not directly align with those defined by the application.
  +<4> The `group` claim provides the groups and top-level roles associated with the JWT bearer.
  +In this quickstart we are only using the top-level role mapping which means the JWT will
  +be seen to have the roles "Echoer", "Tester", "Subscriber" and "group2". The full set of roles would
  +also include a "Group2MappedRole" due to the `roleMappings` claim having a mapping from
  +"group2" to "Group2MappedRole".
  +
   Now we can generate a JWT to use with `TokenSecuredResource` endpoint. To do this, run the following command:
   
   .Command to Generate JWT
  
positive.code: }
  ----
  <1> This new endpoint will be located at /secured/roles-allowed
  <2> @RolesAllowed is a JSR 250 common security annotation that indicates that the given endpoint is accessible by a caller if they have either a "Echoer" or "Subscriber" role assigned.
  
  After you make this addition to your `TokenSecuredResource`, rerun the `mvn compile quarkus:dev` command, and then try `curl -v http://127.0.0.1:8080/secured/roles-allowed; echo` to attempt to access the new endpoint. Your output should be:
  
  
negative.code: This guide explains how your {project-name} application can utilize {mp-jwt} to provide
  secured access to the JAX-RS endpoints.
  
  == Configuration
  
  [cols="<m,<m,<2",options="header"]
  |===
  