Security using API Gateway + Cognito and Bearer JWT Token

[vladaman]

We have integrated AWS API Gateway HTTP API + Cognito and JWT. When we include Bearer keyword in Authorization header we get 401 error from Quarkus.

Returns 401 error

curl -X 'GET' \
  'https://api.mysite.com/0.5/app-user/heyho' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer eyJraWQiOiJ1aVcwcxxxxx'

Response:

< HTTP/2 401 
< date: Tue, 20 Sep 2022 08:03:32 GMT
< content-length: 0
< www-authenticate: Bearer
< apigw-requestid: Yv8JOgAWhAcEMpQ=

Following call succeeds (note, Bearer keyword is not included) but JsonWebToken is null:

curl -X 'GET' \
  'https://api.mysite.com/0.5/app-user/heyho' \
  -H 'accept: application/json' \
  -H 'Authorization: eyJraWQiOiJ1aVcwcxxxxx'

application.properties:

quarkus.lambda-http.enable-security=true

How do I configure Quarkus to accept Authorization header via AWS API Gateway if it includes "Bearer"?

[quarkus-bot[bot]]

/cc @sberyozkin

[sberyozkin]

As far as I recall, Quarkus Amazon Lambda is not integrated with MP-JWT API so JsonWebToken will not be injected, and I'm not sure about the cause of 401 in this case.
@patriot1burke Hi Bill, can you remind please how to trace the token verification issues with quarkus-amazon-lambda ?
Do you recall we also talked about supporting a JsonWebToken injection, no need to do the full MP-JWT compliance - it won't even require depending on smallrye-jwt, would it make sense to revisit it ?
Thanks

[vladaman]

I figured the issue - yes - we had smallrye-jwt as dependency - after we removed this dependency the app started to respond properly and consistently. Regardless if Bearer prefix was included in Authorization header or not.

I assume there is a conflict with smallrye-jwt.

[sberyozkin]

@vladaman Just including quarkus-smallrye-jwt enables it by default, so if you did not configure it to verify it with the Cogito keys and the issuer and possibly an ES256 algorithm (I recall some of Amazon services may use it) then it will fail.
Out of curiosity, how are you verifying the token without quarkus-smallrye-jwt ?

[vladaman]

@sberyozkin we run Lambda behind AWS API Gateway (HTTP) and it does integration with Cognito. So we trust what APIGatewayV2HTTPEvent gives us.
Frankly coudn't figure out any other way. I guess we have to give up RBAC with annotations like @PermitAll etc. Maybe there is a better way.

@RequestScoped
public class CustomJsonWebToken implements Principal {

    private String username;
    private Set<String> groups;
    private Set<String> scopes;
    private Date authTime;
    /**
     * The "exp" (expiration time) claim identifies the expiration time on
     * or after which the JWT MUST NOT be accepted for processing.  The
     * processing of the "exp" claim requires that the current date/time
     * MUST be before the expiration date/time listed in the "exp" claim.
     */
    private Date expireTime;

    /**
     * The "iat" (issued at) claim identifies the time at which the JWT was
     * issued.  This claim can be used to determine the age of the JWT.  Its
     * value MUST be a number containing a NumericDate value.  Use of this
     * claim is OPTIONAL.
     */
    private Date issuedTime;


    private String clientId;

    /**
     * The sub claim identifies the principal that is the subject of the JWT.
     * In other other, it can hold the username of the user who you issued the token to.
     */
    private String subject;
    private String tokenUse;
    private String issuer;

    /**
     * Example Payload in event.getRequestContext().getAuthorizer().getJwt();
     * <p>
     * APIGatewayV2HTTPEvent.RequestContext.Authorizer.JWT(
     * claims={
     * auth_time=1663606395,
     * client_id=xxxx,
     * cognito:groups=[super-admin eu-west-1_xxxx_Google],
     * exp=1663609995,
     * iat=1663606396,
     * iss=https://cognito-idp.eu-west-1.amazonaws.com/eu-west-1_xxxx,
     * jti=xxxxx,
     * scope=aws.cognito.signin.user.admin phone openid profile email,
     * sub=xxxx,
     * token_use=access,
     * username=google_xxxx65616,
     * version=2}, scopes=null)
     *
     * @param event
     */

    public CustomJsonWebToken(APIGatewayV2HTTPEvent event) {
        APIGatewayV2HTTPEvent.RequestContext.Authorizer auth = event.getRequestContext().getAuthorizer();
        if (auth == null) {

            return;
        }

        final APIGatewayV2HTTPEvent.RequestContext.Authorizer.JWT jwt = event.getRequestContext().getAuthorizer().getJwt();

        // Extract groups from JWT Token into a Set
        if (jwt.getClaims().containsKey("cognito:groups")) {
            final String[] grpArr = jwt.getClaims().get("cognito:groups").replaceAll("\\[|\\]", "").split("\\s");
            this.groups = Arrays.stream(grpArr).collect(Collectors.toSet());
        } else {
            this.groups = Collections.emptySet();
        }

        this.scopes = Arrays.stream(jwt.getClaims().get("scope").split("\\s")).collect(Collectors.toSet());
        this.username = jwt.getClaims().get("username");
        this.authTime = new Date(Integer.parseInt(jwt.getClaims().get("auth_time")) * 1000L);
        this.expireTime = new Date(Integer.parseInt(jwt.getClaims().get("exp")) * 1000L);
        this.issuedTime = new Date(Integer.parseInt(jwt.getClaims().get("iat")) * 1000L);

        this.clientId = jwt.getClaims().get("client_id");
        this.tokenUse = jwt.getClaims().get("token_use");
        this.subject = jwt.getClaims().get("sub");
        this.issuer = jwt.getClaims().get("iss");
    }

    @Override
    public String getName() {
        return username;
    }

    @Override
    public boolean implies(Subject subject) {
        return Principal.super.implies(subject);
    }

    public String getSubject() {
        return subject;
    }

    @Override
    public String toString() {
        return "CustomJsonWebToken{" +
                "username='" + username + '\'' +
                ", groups=" + groups +
                ", scopes=" + scopes +
                ", authTime=" + authTime +
                ", expireTime=" + expireTime +
                ", issuedTime=" + issuedTime +
                ", clientId='" + clientId + '\'' +
                ", subject='" + subject + '\'' +
                ", tokenUse='" + tokenUse + '\'' +
                ", issuer='" + issuer + '\'' +
                '}';
    }
}

[sberyozkin]

@vladaman Makes sense, this is a case where the incoming token has already been verified...

It would be good though to have MP JWT JsonWebToken (which is also a Principal) API integrated with quarkus-amazon-lambda, so that users don't have to write such custom code, have a look please if it can be of interest

[sberyozkin]

@vladaman Or may be you could also try smallrye-jwt and the custom factory: https://quarkus.io/guides/security-jwt#custom-factories

[patriot1burke]

Have you seen this?

https://quarkus.io/guides/amazon-lambda-http#custom-security-integration

If you are using Cognito, the only thing the quarkus-amazon-lambda-http extension does is create a principal for you so that it can be propagated throughout the Quarkus security layers. If you are in need of RBAC, then you'll have to establish the SecurityIdentity yourself as per the docs.

When I wrote this integration I was not sure if it was possible to map JWT claims with roles so you could do RBAC. Is there a reliable consistent way to map Cognito claims to Quarkus RBAC?

[sberyozkin]

Hi @patriot1burke From the code example above,

 final String[] grpArr = jwt.getClaims().get("cognito:groups").replaceAll("\\[|\\]", "").split("\\s");

seems most relevant, perhaps quarkus-amazon-lambda-http can check this claim by default and add them as roles to SecurityIdentity ? And possibly also save the original JWT as a SecurityIdentity attribute for the users to have an extra option to customize SecurityIdentity already created by quarkus-amazon-lambda-http by accessing this attribute in SecurityIdentityAugmentor ?

[patriot1burke]

IIRC, they also have scopes. So which is it?

[sberyozkin]

I'd probably go for the groups in the beginning, and and later add a config option if necessary to allow users to use scopes instead. I guess we may also need to look into adding a new annotation specifically for scopes (@Scopes) since roles and scopes can likely be combined (ex, user has to be in the admin role and have a permission to write for this method be accessible, so we'd have both @RolesAllowed and @Scopes)