Initial error handling fixes for token revoke

[jimmyfagan]

JIRA Ticket:
BB2-4985

What Does This PR Do?

What Should Reviewers Watch For?

If you're reviewing this PR, please check if there are other error cases that are messy that you run into. Been pulled in a lot of different directions this week, so I might've lost track of some cases.

Validation

1. Generate a token (either CAN or normal flow)
2. Use that token to retrieve FHIR resources
3. Issue a POST to http://localhost:8000/v[123]/o/revoke_token/ with basic auth clientId:clientSecret, and with request body x-www-form-urlencoded with token:
4. Confirm a 200 response
5. Confirm that the token can no longer be used to retrieve FHIR resources or the refresh token for token refresh.

On step 3, you can also use token: <refresh_token> and token_type_hint: refresh_token. You can and should also try to revoke a token that doesn't exist or one that belongs to another application. All of these cases should result in a 200 status, but you should only be able to revoke a token belonging to the app making the request.

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies
• Modifies any security controls
• Adds new transmission or storage of data
• Any other changes that could possibly affect security?

• Yes, one or more of the above security implications apply. This PR must not be merged without the ISSO or team
  security engineer's approval.

Any Migrations?

• Yes, there are migrations
  • The migrations should be run PRIOR to the code being deployed
  • The migrations should be run AFTER the code is deployed
  • There is a more complicated migration plan (downtime,
    etc)
• No migrations

[Copilot]

Pull request overview

This PR aims to improve error handling around the OAuth2 token revocation endpoint(s), primarily by expanding which OAuth errors are caught during revoke processing and by enhancing application resolution when a token (access/refresh) is provided.

Changes:

• Expanded RevokeTokenView.post() error handling to also catch InvalidRequestError.
• Updated get_application_from_data() to recognize token_type_hint=refresh_token and attempt refresh-token lookup when resolving an application from request data.
• Added new “not found” error handling for missing access/refresh tokens during application resolution.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
apps/dot_ext/views/authorization.py	Extends revoke pre-validation error handling before delegating to DOT’s revoke implementation.
apps/dot_ext/utils.py	Adjusts application resolution from request payload (including refresh token hinting and token-not-found handling).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JamesDemeryNava]

Looks good! Validation steps all worked for me, all three versions, with token_type_hint, etc. There is one unit test that now will need to expect an HTTPStatus.OK result, that test is test_revoked_token_on_inactive_app.

Given this is time sensitive, should we write a follow up ticket to add a unit or integration test that creates a token, calls the revoke token endpoint, then runs a FHIR resource call with that token, and receives a 401?

[jimmyfagan]

@JamesDemeryNava I pushed changes, in fixing unit tests, I noticed that according to https://datatracker.ietf.org/doc/html/rfc7009#section-2, we should still have validation of the client before trying to revoke the token, so some 200 cases in the last review should actually be 403 or 401.

[JamesDemeryNava]

Looks good, all validation steps working as expected. Just one question about the token that DNE case, and if we're okay with a 500 there, or if we want a different error.

[JamesDemeryNava]

Looks good! Confirmed a 200 status code when passing a token that DNE (with token_type_hint and without)