2.11. Testing the application

For more information about testing your application in dev mode, see the preceding Running the application in dev mode section.

You can test the application launched in JVM or Native modes with curl.

Obtain an access token for alice:

export access_token=$(\
    curl --insecure -X POST http://localhost:8180/realms/quarkus/protocol/openid-connect/token \
    --user backend-service:secret \
    -H 'content-type: application/x-www-form-urlencoded' \
    -d 'username=alice&password=alice&grant_type=password' | jq --raw-output '.access_token' \
 )

Use this token to call /frontend/user-name-with-propagated-token. This command returns the 200 status code and the name alice:

curl -i -X GET \
  http://localhost:8080/frontend/user-name-with-propagated-token \
  -H "Authorization: Bearer "$access_token

Use the same token to call /frontend/admin-name-with-propagated-token. In contrast to the preceding command, this command returns 403 because alice has only a user role:

curl -i -X GET \
  http://localhost:8080/frontend/admin-name-with-propagated-token \
  -H "Authorization: Bearer "$access_token

Next, obtain an access token for admin:

export access_token=$(\
    curl --insecure -X POST http://localhost:8180/realms/quarkus/protocol/openid-connect/token \
    --user backend-service:secret \
    -H 'content-type: application/x-www-form-urlencoded' \
    -d 'username=admin&password=admin&grant_type=password' | jq --raw-output '.access_token' \
 )

Use this token to call /frontend/user-name-with-propagated-token. This command returns a 200 status code and the name admin:

curl -i -X GET \
  http://localhost:8080/frontend/user-name-with-propagated-token \
  -H "Authorization: Bearer "$access_token

Use the same token to call /frontend/admin-name-with-propagated-token. This command also returns the 200 status code and the name admin because admin has both user and admin roles:

curl -i -X GET \
  http://localhost:8080/frontend/admin-name-with-propagated-token \
  -H "Authorization: Bearer "$access_token

Next, check the FrontendResource methods, which do not propagate the existing tokens but use OidcClient to get and propagate the tokens. As already shown, OidcClient is configured to get the tokens for the alice user.

curl -i -X GET \
  http://localhost:8080/frontend/user-name-with-oidc-client-token

This command returns the 200 status code and the name alice.

curl -i -X GET \
  http://localhost:8080/frontend/admin-name-with-oidc-client-token

In contrast with the preceding command, this command returns a 403 status code.

Next, test that the programmatically created OIDC client correctly acquires and propagates the token with RestClientWithTokenHeaderParam both in reactive and imperative (blocking) modes.

Call the /user-name-with-oidc-client-token-header-param. This command returns the 200 status code and the name alice:

curl -i -X GET \
  http://localhost:8080/frontend/user-name-with-oidc-client-token-header-param

Call the /admin-name-with-oidc-client-token-header-param. In contrast with the preceding command, this command returns a 403 status code:

curl -i -X GET \
  http://localhost:8080/frontend/admin-name-with-oidc-client-token-header-param

Next, test the endpoints which use OIDC client in in the blocking mode.

Call the /user-name-with-oidc-client-token-header-param-blocking. This command returns the 200 status code and the name alice:

curl -i -X GET \
  http://localhost:8080/frontend/user-name-with-oidc-client-token-header-param-blocking

Call the /admin-name-with-oidc-client-token-header-param-blocking. In contrast with the preceding command, this command returns a 403 status code:

curl -i -X GET \
  http://localhost:8080/frontend/admin-name-with-oidc-client-token-header-param-blocking