1. Send a request using curl.
    curl --insecure --location --request POST 'https://localhost:7443/meme-game/api/v1/games' \
    --header 'Authorization: Bearer { "active": true, "sub": "user.99@example.com" }' \
    --header 'Content-Type: application/json' \
    --data-raw '{
        "data": {
            "type": "game",
            "attributes": {
                "invitees": [
                    "user.99@example.com"
                ]
            }
        }
    }'

    You should receive an error response with a response status of 403 Forbidden.

    The request has an access token value of { "active": true, "sub": "user.99@example.com" }. The sub field of the access token corresponds to the HttpRequest.AccessToken.subject Trust Framework attribute that your policy uses to make its decision.

  2. As an experiment, edit the access token value in curl to change the sub value to an email address for a different domain. What should happen with this new request?
    Send a request using curl.
    curl --insecure --location --request POST 'https://localhost:7443/meme-game/api/v1/games' \
    --header 'Authorization: Bearer { "active": true, "sub": "user.99@my-company.com" }' \
    --header 'Content-Type: application/json' \
    --data-raw '{
        "data": {
            "type": "game",
            "attributes": {
                "invitees": [
                    "user.99@example.com"
                ]
            }
        }
    }'

    The HTTP response status should now be 201 Created.

    To better understand how policy decisions work, see For further consideration: Decision Visualiser.