Odnoklassniki (OK.ru) Login Integration for Mobile Apps

Social Login via Odnoklassniki for Mobile Apps

One frequent mistake in Odnoklassniki (OK.ru) authorization integration is confusion between three keys: application_id, application_key, and application_secret_key. We’ve encountered projects where application_secret_key was baked into the mobile client, compromising security entirely. The correct approach is to store application_secret_key on the server and perform signed requests from there. OK uses OAuth2, but with mandatory request signing—unlike classic providers. This makes integration 2-3 times more involved compared to VK, but adds an extra security layer.

Problems We Solve

Key Management Confusion – Developers often misuse application_key and application_secret_key. We ensure correct usage: application_key is used in signing, application_secret_key never leaves the server.

Signature Errors (PARAM_SIGNATURE_INVALID) – This is the most common issue. Incorrect parameter ordering or missing MD5 steps cause failures. Our backend implementation guarantees proper signing every time.

Token Refresh Gaps – Many projects ignore the 30-day token expiration. We implement a full refresh flow on the server side, so users stay logged in without interruptions.

How We Do It (Case Example)

On a recent project for a social app with 50k users, we integrated OK login alongside existing VK and Google providers. The client had already attempted integration but was stuck with signature errors for weeks. We audited their flow:

• Issue: The iOS app was building the signed request locally using application_secret_key hardcoded in Swift.
• Fix: We moved all signing to a Node.js backend. The mobile client sent the access_token to our endpoint, which constructed and signed the request.
• Result: Signature errors eliminated, security improved, and the client saved an estimated 3 days of debugging per month.

The core signing logic:

const md5 = require('md5'); function signRequest(params, accessToken, secretKey) { const sortedKeys = Object.keys(params).sort(); let sortedString = ''; for (let key of sortedKeys) { sortedString += key + '=' + params[key]; } const innerHash = md5(accessToken + secretKey); const sig = md5(sortedString + innerHash); return sig; } 

Process and Timelines

1. Discovery (1-2 days): Clarify requirements, prepare integration scheme.
2. Design (1 day): Choose stack (iOS/Android/cross-platform), design architecture.
3. SDK & OAuth2 Integration (2-3 days): Embed OK SDK, implement login flow.
4. Server-Side Signing & API (2-3 days): Build signing logic, profile retrieval (users.getCurrentUser), token verification.
5. Testing (1-2 days): Test on devices with/without OK app, verify refresh token.
6. Deployment & Acceptance (1 day): Release and handover.

Timelines: From 5 to 12 working days. Cost is calculated individually after analysis.

Common Mistakes to Avoid

• Storing application_secret_key on the client – Leads to token theft via decompilation.
• Missing refresh token flow – Users forced to log in every 30 days, increasing drop-off.
• Skipping server-side uid verification – Attackers could forge tokens; always verify uid via users.getLoggedInUser?access_token={token}.
• Incorrect parameter sorting – Must be alphabetical, case-sensitive as per OK API docs.

Comparison: OK SDK vs Direct HTTP

What’s Included in Our Work

• App registration on apiok.ru and key obtainment.
• OK SDK integration (iOS/Android or cross-platform).
• OAuth2 flow with refresh token support.
• Server-side request signing, token verification, profile retrieval.
• Usage documentation.
• Testing on devices with/without the OK app.
• Warranty support (3 months).

We have 5+ years of experience integrating social networks and have completed 20+ projects with OK authorization. Contact us for a project evaluation—we’ll tailor the best solution. Get a consultation before development starts.

If you’re facing non-obvious issues with your current integration, order an audit of your implementation—it saves time and budget.