Login parameters, signature algorithms, callback fields and application review requirements may change. Before accessing, please obtain the current SDK and official technical documentation from Potato.
Standard authorization process
Create Application
Register the application name, domain name, callback address and support information.
Initiate authorization
Generate an authorization request with status parameters and jump to Potato.
User Confirmation
Display the requested information and purpose to the user, and the user actively agrees.
Server-side verification
Authenticate callbacks, exchange credentials, and establish your own login session.
Data and permission scope
Only request information necessary to create an account, identify the user, or complete the current business. Do not interpret login authorization as permission to access contacts, chats, or other irrelevant data.
- Explain the purpose and retention period of the data before authorization
- Provide skipping or supplementing later for optional information
- Bind local account with stable platform identification
- Provide an entrance to unbind and delete accounts
Security design
- Use an exact matching HTTPS callback address and disable open redirects.
- Use random state or equivalent mechanism to prevent cross-site request forgery.
- Authorization codes are only exchanged on the server side, and client keys must not be exposed.
- Verify signature, issuer, audience, time and replay risk.
- Set reasonable duration, revocation capabilities, and exception login notifications for sessions.
Do not trust user information directly transmitted from the front end.Successful account creation and login must be based on authorization verification completed by the server.
Exceptions and account conflicts
| Scenario | Recommended treatments |
|---|---|
| User cancellation of authorization | Return to the original page and retain the filled-in content without displaying it as a system error |
| Status parameter mismatch | Terminate login, clean up temporary sessions and record security events |
| Authorization code expired or used | Reinitiate authorization, do not repeat exchange |
| Already have an account with the same email or mobile phone number | Require users to verify the original account before binding, prohibit automatic merging |
| Platform service is temporarily unavailable | Display retry prompts and retain other login methods |
Online Check
- Production and test applications, keys and callbacks are completely isolated
- Privacy policy explains login data and deletion method
- Authorization cancellation, timeout and repeat callbacks have been tested
- Support unbinding and account recovery
- The log does not contain authorization codes, tokens or complete personal data
- Provide security incident response and key rotation process