Rake tasks for appeals CCG auth

[caseywilliams]

Adds new rake tasks for fetching and validating Client Credentials Grant (CCG) tokens for appeals APIs that use OAuth

Summary

• Adds the following new rake tasks:

rake appeals_api:token:as:ccg             # Get a CCG token for appeals_status
rake appeals_api:token:as:validate        # Validate an OpenID (CCG or Okta) token for appeals_status
rake appeals_api:token:ci:ccg             # Get a CCG token for contestable_issues
rake appeals_api:token:ci:validate        # Validate an OpenID (CCG or Okta) token for contestable_issues
rake appeals_api:token:hlr:ccg            # Get a CCG token for higher_level_reviews
rake appeals_api:token:hlr:validate       # Validate an OpenID (CCG or Okta) token for higher_level_reviews
rake appeals_api:token:la:ccg             # Get a CCG token for legacy_appeals
rake appeals_api:token:la:validate        # Validate an OpenID (CCG or Okta) token for legacy_appeals
rake appeals_api:token:nod:ccg            # Get a CCG token for notice_of_disagreements
rake appeals_api:token:nod:validate       # Validate an OpenID (CCG or Okta) token for notice_of_disagreements
rake appeals_api:token:sc:ccg             # Get a CCG token for supplemental_claims
rake appeals_api:token:sc:validate        # Validate an OpenID (CCG or Okta) token for supplemental_claims

• New settings in settings.yml support these tasks:
  • modules_appeals_api.token_generation.config_uri should be the URI to the well-known configuration for the auth server
  • modules_appeals_api.token_generation.ccg should have a client_id from https://developer.va.gov/onboarding/request-sandbox-access or https://dev-developer.va.gov/onboarding/request-sandbox-access, and the private_key_path to the key used to generate the jwk that was submitted to the form.
• Each ccg task generates a CCG token that has all valid scopes for the given API
  • So, for example, the appeals_api:token:hlr:ccg task generates a token with the scopes appeals/HigherLevelReviews.read and appeals/HigherLevelReviews.write
  • The token creation endpoint response is printed to the console
• Each validate task validates a token
  • These tasks prompt the user interactively for a token and query the token validation service for its status and details (including its scopes)
  • The token validation service's response is printed to the console
  • These tasks rely on the token validation service key settings added to settings.yml in Update scopes and key usage in appeals OAuth APIs #11727 (for example, appeals_api:token:hlr:validate attempts to validate a token using the token validation key for HLR)
  • This PR does not attempt to generate Okta tokens (for individual users), but this task will also work for Okta tokens - the same token validation service endpoint validates both kinds of token

Related issue(s)

API-22478, API-22479, API-22480, API-22481, API-22482, API-22483 are the individual tickets for each API.

Testing done

• Manually ran each task to fetch and validate tokens for each API
• The process of getting a Client ID for the new APIs is not automated yet, so it will be hard for anyone else to test this without help. To make things easier, I can send my development settings.local.yml values for these tasks to teammates via keybase if anyone wants to try these out.

What areas of the site does it impact?

None, only adds rake tasks.

Acceptance criteria

- [ ] I fixed|updated|added unit tests and integration tests for each feature (if applicable).

• No error nor warning in the console.
  - [ ] Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
  - [ ] Feature/bug has a monitor built into Datadog or Grafana (if applicable)
  - [ ] If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
  - [ ] I added a screenshot of the developed feature