Developing Odnoklassniki Authorization
Odnoklassniki (OK.ru) authorization — OAuth2 over proprietary API. The audience is specific: 35+ years old, actively uses the Odnoklassniki mobile app. If your product targets this demographic or integrates with the social network (games, contests, UGC) — integration is justified.
SDK and setup
OK provides OKiOS SDK (CocoaPods: pod 'OKiOS') and OK Android SDK (Gradle: implementation 'ru.ok.android:sdk:latest'). The SDK is arranged similarly to VK: if the OK app is present on the device — authorization through it without password entry, otherwise — browser OAuth2.
App registration on apiok.ru, we get application_id, application_key, application_secret_key. Three keys — typical confusion. application_key is used when signing requests to the API, application_secret_key — server-side, never in the client.
On iOS URL Scheme: ok{application_id}. In AppDelegate — [OKSDK handleOpenURL:url].
After authorization we get access_token and refresh_token. OK tokens have limited TTL (usually 30 days), refresh is mandatory.
Requests to OK API
A peculiarity of OK API — mandatory request signing. Request parameters are sorted alphabetically, concatenated, an MD5 of access_token + application_secret_key is added to the string, then MD5 of the entire string. Without correct signature — PARAM_SIGNATURE_INVALID error.
sig = MD5( sorted_params_string + MD5(access_token + application_secret_key) )
This logic — on the server side. The mobile client passes access_token to the backend, the backend makes signed requests to OK API.
Profile method: users.getCurrentUser with fields name,pic_3,email. Email in OK — optional field, user may not have specified it.
Server token verification: users.getLoggedInUser?access_token={token} — returns user uid if token is valid.
Timeframe: 3–6 business days. Non-standard API signature complicates the server side compared to classic OAuth2 providers.