-
-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: revocation inconsistencies and match oauth spec rfc7009 #152
Conversation
jasonraimondi
commented
Aug 8, 2024
- requires client credentials authentication over the revoke endpoint
- properly support token_type_hint access_token and revoke_token
- previously only token_type_hint refresh_token was supported
- extends the token_type_hint parameter to support 'auth_code' revocation
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
13251990 | Triggered | Generic High Entropy Secret | 8d14378 | test/e2e/authorization_server.spec.ts | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
76ca09c
to
e52dd7f
Compare
@@ -322,4 +306,38 @@ export class AuthCodeGrant extends AbstractAuthorizedGrant { | |||
await this.authCodeRepository.persist(authCode); | |||
return authCode; | |||
} | |||
|
|||
canRespondToRevokeRequest(request: RequestInterface): boolean { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
auth codes can be revoked with token_type_hint=auth_code
return response; | ||
} | ||
|
||
canRespondToRevokeRequest(request: RequestInterface): boolean { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the server will assume that the token is an access_token, so all other revoke requests besides auth_code should come to the client credentials grant and if it is missing a token, it will throw, and then if it is not an access/refresh token, it will throw, etc.
- requires client credentials authentication over the revoke endpoint - properly support token_type_hint access_token and revoke_token - previously only token_type_hint refresh_token was supported - extends the token_type_hint parameter to support 'auth_code' revocation
e52dd7f
to
8d14378
Compare
The breaking change here is requiring client credentials authorization to the revoke endpoint |