-
Notifications
You must be signed in to change notification settings - Fork 373
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
feat(appcheck): Added replay protection feature to App Check verifyToken()
API
#2148
Conversation
25c8d58
to
748dcec
Compare
return true; | ||
}) | ||
.catch((err) => { | ||
throw this.toFirebaseError(err); |
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.
(Just for informational purposes, no action needed.) Right now the backend has two main error conditions (in this order of priority):
- If the token is invalid (expired, invalid signature, wrong audience, etc.), an HTTP 403 Forbidden will be returned.
- If the token had a provider of
safety_net
, an HTTP 400 Bad Request will be returned. (Maybe we could even detect this early and avoid the network call?)
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.
Ah good point! Since we check the validity of the token prior to making the call to BE, 1) should be addressed already. How do we check 2)?, is it a custom claim encoded in the JWT?
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.
For (2), yes, it is actually a private claim named provider
in the JWT, but now that I think about this more, I think a more robust method for detecting whether the token supports Replay Protection is to see whether its jti
claim is populated with a nonempty string rather than checking the provider
claim against a hardcoded list of allowed providers.
c51e981
to
913d149
Compare
src/app-check/app-check-api.ts
Outdated
@@ -41,6 +41,27 @@ export interface AppCheckTokenOptions { | |||
ttlMillis?: number; | |||
} | |||
|
|||
/** | |||
* Interface representing options for {@link AppCheck.verifyToken} method. |
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.
* Interface representing options for {@link AppCheck.verifyToken} method. | |
* Interface representing options for the {@link AppCheck.verifyToken} method. |
src/app-check/app-check-api.ts
Outdated
* To use the replay protection feature, set this to true to mark the token as consumed. | ||
* Tokens that are found to be already consumed will be marked as such in the response. |
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.
* To use the replay protection feature, set this to true to mark the token as consumed. | |
* Tokens that are found to be already consumed will be marked as such in the response. | |
* To use the replay protection feature, set this to true. The {@link AppCheck.verifyToken} | |
* method will mark the token as consumed after verifying it. | |
* | |
* Tokens that are found to be already consumed will be marked as such in the response. |
verifyToken()
API
RELEASE NOTE: Added replay protection feature to App Check
verifyToken()
API.