You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently using react-native-iap for implementing in-app purchases in my app. I've noticed that in SK2 mode, the library internally validates the JWS signed transaction and returns decoded values. While this is efficient, considering security best practices, it might be beneficial to also provide the option of server-side validation.
As per my understanding, the library, in SK2 mode, internally validates the JWS signed transaction and then returns decoded values (as discussed in issue #2047). However, this approach seems potentially less secure since the JWS signedTransaction, ideally, should be passed to the server for validation.
As the library only returns decoded values, currently, my workaround involves:
Obtaining the originalTransactionId from react-native-iap.
Sending this ID to my server.
Having the server request transaction info from the Apple Server (Get Transaction Info).
Validating that the transaction exists and is valid.
This process, however, seems as complex as, or even more complicated than, using old verifyReceipt, since it still requires fetching validation from the Apple Server.
As per Apple's WWDC 2021 presentation, the introduction of JWS signedTransaction is meant to enable independent validation by app servers. Though client-side validation is an option, there are potential security risks, especially when dealing with sensitive financial transactions.
From the WWDC21 video (around 6:30):
Now, I want to talk about verifying the signature portion of the signed transaction info.
Verifying the signature is an option for you to validate that the transaction came from Apple and is trustworthy.
If you only want to see the contents of the transaction, this step is not required.
However, to verify the signature, you will need to use the claims available in the header portion of the signed transaction info.
Use the alg claim to know what signing algorithm we used, and use the certificate chain in the array in the x5c claim.
Once you have these two things, you can use your favorite cryptographic library to verify the signature of the signed transaction info.
Given that I have my own server, I cannot rely solely on client-side validation for security reasons. It seems more appropriate to have JWS signedTransactions passed along after a purchase is made, which I can then send to my server for verification.
Therefore, I suggest enhancing the react-native-iap library to expose the JWS signedTransaction post-purchase. This would allow developers to choose between client-side validation for efficiency or server-side validation for enhanced security, aligning with Apple's flexibility in handling these transactions.
If there are aspects of this implementation that I have misunderstood, or if this topic has already been discussed within the community, I'd appreciate any insights or corrections.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
I am currently using react-native-iap for implementing in-app purchases in my app. I've noticed that in SK2 mode, the library internally validates the JWS signed transaction and returns decoded values. While this is efficient, considering security best practices, it might be beneficial to also provide the option of server-side validation.
As per my understanding, the library, in SK2 mode, internally validates the JWS signed transaction and then returns decoded values (as discussed in issue #2047). However, this approach seems potentially less secure since the JWS signedTransaction, ideally, should be passed to the server for validation.
As the library only returns decoded values, currently, my workaround involves:
originalTransactionId
from react-native-iap.This process, however, seems as complex as, or even more complicated than, using old
verifyReceipt
, since it still requires fetching validation from the Apple Server.As per Apple's WWDC 2021 presentation, the introduction of JWS signedTransaction is meant to enable independent validation by app servers. Though client-side validation is an option, there are potential security risks, especially when dealing with sensitive financial transactions.
From the WWDC21 video (around 6:30):
Given that I have my own server, I cannot rely solely on client-side validation for security reasons. It seems more appropriate to have JWS signedTransactions passed along after a purchase is made, which I can then send to my server for verification.
Therefore, I suggest enhancing the react-native-iap library to expose the JWS signedTransaction post-purchase. This would allow developers to choose between client-side validation for efficiency or server-side validation for enhanced security, aligning with Apple's flexibility in handling these transactions.
If there are aspects of this implementation that I have misunderstood, or if this topic has already been discussed within the community, I'd appreciate any insights or corrections.
Thank you for considering this enhancement.
Beta Was this translation helpful? Give feedback.
All reactions