[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eThe phone verification server creates a verification message with a one-time code, sends it to the user's device via SMS, and verifies the code when the client returns it.\u003c/p\u003e\n"],["\u003cp\u003eThe verification message must be 140 bytes or less, contain a one-time code and an 11-character app hash string for Google Play services to identify your app.\u003c/p\u003e\n"],["\u003cp\u003eGenerate one-time codes securely on the server, ensuring they're unguessable, linkable to the user, and easy to type for manual entry if needed.\u003c/p\u003e\n"],["\u003cp\u003eCompute your app's hash string using your package name and signing certificate, then include it in the verification message for automatic retrieval by the SMS Retriever API.\u003c/p\u003e\n"],["\u003cp\u003eAfter verifying the returned one-time code, update the user's verification status in your system and invalidate the code to prevent reuse.\u003c/p\u003e\n"]]],[],null,["# Perform SMS Verification on a Server\n\nTo automatically verify phone numbers, you must implement both the client and\nserver portions of the verification flow. This document describes how to\nimplement the server portion.\n\nThe phone verification server is responsible for three tasks:\n\n1. Constructing a verification message that includes a one-time code and has the format the client-side SMS Retriever API expects\n2. Sending the verification message to to the user's device\n3. Verifying the one-time code when it's sent back to the server and completing any post-verification tasks your backend requires\n\nThe specifics of how your app interacts with the server are up to you. A common\napproach is to expose a REST API with two endpoints: one that receives requests\nto verify a given phone number and sends the SMS verification messages, and a\nsecond endpoint that receives one-time codes from your app.\n\n1. Construct a verification message\n-----------------------------------\n\nWhen your server receives a request to verify a phone number, first construct\nthe verification message that you will send to the user's device. This message\nmust:\n\n- Be no longer than 140 bytes\n- Contain a one-time code that the client sends back to your server to complete the verification flow (see [Generating a one-time code](#generating_a_one-time_code))\n- Include an 11-character hash string that identifies your app (see [Computing your app's hash string](#computing_your_apps_hash_string))\n\nOtherwise, the contents of the verification message can be whatever you choose.\nIt is helpful to create a message from which you can easily extract the one-time\ncode later on. For example, a valid verification message might look like the\nfollowing: \n\n```\nYour ExampleApp code is: 123ABC78\n\nFA+9qCX9VSu\n```\n\n\u003cbr /\u003e\n\n### Generating a one-time code\n\nYou can implement one-time codes in many ways, as long as the codes are\nunguessable and you can link the codes to a user or phone number when the client\napp sends them back to your server. You should make the codes easy to type, to\naccommodate any situations which might require users to manually type the code.\n\nOne way to implement one-time codes is to generate random numbers, which you use\nas keys in a database table. For example, you might have a PendingVerifications\ntable like the following:\n\n| ID | User | Expiration |\n|--------------|------|----------------|\n| 123456789... | 1234 | 2017-3-14 1:59 |\n\nYou can use the base32-encoded ID as a one-time code.\n\n### Computing your app's hash string\n\nGoogle Play services uses the hash string to determine which verification\nmessages to send to your app. The hash string is made of your app's package name\nand your app's public key certificate. To generate the hash string:\n\n1. If you use [app signing by Google Play](https://support.google.com/googleplay/android-developer/answer/7384423),\n download your app signing certificate (`deployment_cert.der`) from the\n **App signing** section of the [Google Play console](https://play.google.com/apps/publish/).\n\n Then, import the app signing certificate into a temporary key store: \n\n ```\n keytool -importcert -file deployment_cert.der -keystore temporary.keystore -alias PlayDeploymentCert\n ```\n\n \u003cbr /\u003e\n\n If you sign your APKs directly, skip this step.\n2. Get your app signing certificate---either the one you imported above or\n the one you use to sign your APKs directly---as a lower-case hex string.\n\n For example, to get the hex string from the temporary keystore created\n above, type the following command: \n\n ```\n keytool -exportcert -keystore temporary.keystore -alias PlayDeploymentCert | xxd -p | tr -d \"[:space:]\"\n ```\n\n \u003cbr /\u003e\n\n If you sign your APKs directly, specify your production keystore and\n certificate alias.\n3. If you created a temporary keystore, delete it.\n\n4. Append the hex string to your app's package name, separated by a single\n space.\n\n5. Compute the SHA-256 sum of the combined string. Be sure to remove any\n leading or trailing whitespace from the string before computing the SHA-256\n sum.\n\n6. Base64-encode the binary value of the SHA-256 sum. You might need to decode\n the SHA-256 sum from its output format first.\n\n7. Your app's hash string is the first 11 characters of the base64-encoded\n hash.\n\nThe following command computes the hash string from your app's production\nkeystore: \n\n```\nkeytool -exportcert -alias PlayDeploymentCert -keystore MyProductionKeys.keystore | xxd -p | tr -d \"[:space:]\" | echo -n com.example.myapp `cat` | sha256sum | tr -d \"[:space:]-\" | xxd -r -p | base64 | cut -c1-11\n```\n| **Note:** This command does not emit an error if the `keytool` command fails (for example, because the alias does not exist within the keystore). Before you run the entire pipeline, try running the `keytool` command by itself to ensure it's producing meaningful output.\n\nAlternatively, you can get your app's hash string with the [AppSignatureHelper](https://github.com/googlesamples/android-credentials/blob/master/sms-verification/android/app/src/main/java/com/google/samples/smartlock/sms_verify/AppSignatureHelper.java)\nclass from the SMS retriever sample app. However, if you use the helper class,\nbe sure to remove it from your app after you get the hash string. **Do not use\nhash strings dynamically computed on the client in your verification messages.**\n\n2. Send the verification message by SMS\n---------------------------------------\n\nAfter you construct the verification message, send the message to the user's\nphone number using any SMS system.\n\nFor example, see [App verification using Twilio SMS](https://www.twilio.com/docs/api/rest/app-verification-using-twilio-sms)\non Twilio's developer site.\n| **Important:** Don't send the one-time code or verification message back to the user's device through any channel other than SMS. In particular, don't return the one-time code in response the verification request for the purpose of client-side verification. You must generate and verify one-time codes only on the server.\n\nWhen the user's device receives this message, the message is directed to your\napp. Your app extracts the one-time code and sends it back to your server to\ncomplete the verification process.\n\n3. Verify the one-time code when it's returned\n----------------------------------------------\n\nA phone number verification server typically has a second endpoint that it uses\nto receive one-time codes back from client apps. When your server receives a\none-time code from your app at this endpoint, do the following:\n\n1. Verify that the one-time code is valid and has not expired.\n2. Record that the user linked to the one-time code has completed phone number verification.\n3. Remove the one-time code's database record, or in some other way ensure that the same code can't be used again.\n\nWhen you record the user's verification status and remove one-time code from\nyour database, verification is complete."]]