INEX SSO (INEX ID)
OpenID ConnectINEX ID არის ინექსის ერთიანი ავტორიზაციის სერვისი. მისი საშუალებით თქვენი მომხმარებელი თქვენს პლატფორმაზე შედის თავისი INEX-ის ანგარიშით — ცალკე რეგისტრაციისა და პაროლის გარეშე — ხოლო თქვენ იღებთ მის მუდმივ, უნიკალურ იდენტიფიკატორს (sub), რომლითაც შემდეგ ამანათს მის სახელზე ქმნით პირადი ნომრის ხელახლა მოთხოვნის გარეშე.
სტანდარტი
openid-client Node.js-ისთვის, league/oauth2-client / jumbojett/openid-connect-php PHP-სთვის, Spring Security, ASP.NET Core OpenIdConnect, AppAuth მობილურისთვის) — ხელით დაწერა საჭირო არ არის.
რას იღებთ
- ერთი ღილაკით შესვლა — „INEX-ით შესვლა“ — თქვენს ვებსა და მობილურ აპლიკაციაში.
- რეგისტრაცია INEX-ის მხარეს: სახელი, გვარი, ელ. ფოსტა და ტელეფონი (ორივე კოდით დადასტურებული) და პირადი ნომერი. თქვენ მომხმარებლის მონაცემების შეგროვება აღარ გჭირდებათ.
- Google და Apple ანგარიშით შესვლა, პაროლის აღდგენა და ანგარიშებს შორის გადართვა — ყველაფერი INEX ID-ის გვერდებზე.
-
მუდმივი იდენტიფიკატორი
sub, რომელსაც ამანათის შექმნისასreceiver.inexUserIdველში გადმოგვცემთ.
გარემოები
Issuer ორივე გარემოში ზუსტად ასე იწერება (ბოლოში /-ის გარეშე) — id_token-ის iss ველი მას სიმბოლო-სიმბოლოს უნდა დაემთხვეს. Client ID-ები და secret-ები გარემოებს შორის არ ემთხვევა: სატესტოსა და საპროდაქშენოსთვის ცალ-ცალკე მიიღებთ.
Discovery დოკუმენტი
ყველა endpoint-ის მისამართი, მხარდაჭერილი scope-ები, claim-ები და ხელმოწერის ალგორითმი ქვეყნდება სტანდარტულ მისამართზე /.well-known/openid-configuration. OIDC ბიბლიოთეკების უმეტესობას მხოლოდ issuer-ის მისამართი სჭირდება — დანარჩენს თავად წაიკითხავს აქედან.
Endpoint-ები
| Endpoint | Method | დანიშნულება |
|---|---|---|
| /.well-known/openid-configuration | GET | კონფიგურაციის დოკუმენტი (Discovery). |
| /oauth/authorize | GET | მომხმარებლის გადამისამართება შესასვლელად / დასარეგისტრირებლად. |
| /oauth/token | POST | კოდის გაცვლა ტოკენებზე, ტოკენის განახლება (სერვერიდან). |
| /userinfo | GET | მომხმარებლის მიმდინარე მონაცემები access token-ით. |
| /oauth/jwks | GET | id_token-ის ხელმოწერის შესამოწმებელი საჯარო გასაღებები (JWKS). |
| /oauth/logout | GET | INEX ID-იდან გამოსვლა (RP-Initiated Logout). |
როგორ მუშაობს — ნაბიჯ-ნაბიჯ
-
1
მომხმარებელი აჭერს „INEX-ით შესვლა“
თქვენი სერვერი აგენერირებს
state-ს,nonce-ს და PKCE წყვილს, ინახავს მათ მომხმარებლის სესიაში და ბრაუზერს გადაამისამართებს/oauth/authorize-ზე. -
2
ავტორიზაცია INEX ID-ზე
მომხმარებელი შედის (ელ. ფოსტა/ტელეფონი + პაროლი, Google, Apple) ან რეგისტრირდება. თუ ბრაუზერში უკვე შესულია, ფორმა საერთოდ არ ჩანს — ის მაშინვე ბრუნდება უკან.
-
3
დაბრუნება თქვენთან კოდით
INEX ID ბრაუზერს აბრუნებს თქვენს რეგისტრირებულ
redirect_uri-ზე?code=…&state=…პარამეტრებით. ამოწმებთ, რომstateემთხვევა შენახულს. -
4
კოდის გაცვლა ტოკენებზე
თქვენი სერვერი
POST /oauth/token-ით ცვლის კოდს და იღებსaccess_token-ს,refresh_token-ს დაid_token-ს. -
5
id_token-ის შემოწმება
ამოწმებთ ხელმოწერას (JWKS),
iss-ს,aud-ს,exp-ს დაnonce-ს. წარმატების შემთხვევაში იღებთsub-ს და პროფილის მონაცემებს. -
6
მომხმარებლის მიბმა
ინახავთ
sub-ს თქვენს მომხმარებელთან. თუ ესsubუკვე გაქვთ — ეს იგივე ადამიანია; თუ არა — ქმნით ახალ ლოკალურ ანგარიშს ან აბამთ არსებულს. -
7
ამანათის შექმნა
შეკვეთის გაფორმებისას იძახებთ
POST /integrators/parcels/create-ს და მიმღებს უთითებთreceiver.inexUserId = sub— პირადი ნომრის, სახელისა და ტელეფონის გარეშე.
მიერთების პროცესი
Client-ს (თქვენს აპლიკაციას) INEX-ის ტექნიკური გუნდი არეგისტრირებს. გამოგვიგზავნეთ თითოეული გარემოსთვის:
აპლიკაციის სახელი და ლოგო
ჩანს INEX ID-ის შესვლის გვერდზე: „თქვენი აპლიკაცია-ში შესვლა INEX-ით“. ლოგო — კვადრატული PNG/SVG.
ვებ-გვერდი, კონფიდენციალურობის პოლიტიკა, წესები და პირობები
ბმულები, რომლებიც ფორმაზე თქვენი აპლიკაციის სახელთან ჩანს.
Redirect URI-ების სია
ზუსტი მისამართები (სქემა, ჰოსტი, პორტი, გზა), სადაც მომხმარებელი დაბრუნდება კოდით, და სადაც დაბრუნდება გამოსვლის შემდეგ. შედარება ხდება ზუსტი დამთხვევით — wildcard-ები არ მუშაობს. საპროდაქშენოში მხოლოდ HTTPS.
Client-ის ტიპი
Confidential (რეკომენდებული) — კოდს ცვლის თქვენი სერვერი და იყენებს client_secret-ს. Public — მობილური აპლიკაცია ან SPA, რომელიც secret-ს ვერ ინახავს; ასეთი client მხოლოდ PKCE-ზე დგას.
სერვერების საჯარო IP მისამართები
იმ შემთხვევაში, თუ ამანათებსაც ქმნით ჩვენი Integrator API-ით (ჩვეულებრივი IP Whitelist).
სანაცვლოდ მიიღებთ client_id-ს და (confidential client-ის შემთხვევაში) client_secret-ს. Secret ჩვენთან მხოლოდ ჰეშის სახით ინახება და მისი ხელახლა ნახვა შეუძლებელია — დაკარგვის შემთხვევაში ახალს გამოგიშვებთ.
client_secret
client_secret არასოდეს ჩასვათ ფრონტენდის კოდში, მობილურ აპლიკაციაში ან ბრაუზერში ხილულ ადგილას. ტოკენზე გაცვლა ყოველთვის სერვერიდან უნდა მოხდეს.
curl https://id-staging.inex.ge/.well-known/openid-configuration{
"issuer": "https://id-staging.inex.ge",
"authorization_endpoint": "https://id-staging.inex.ge/oauth/authorize",
"token_endpoint": "https://id-staging.inex.ge/oauth/token",
"userinfo_endpoint": "https://id-staging.inex.ge/userinfo",
"jwks_uri": "https://id-staging.inex.ge/oauth/jwks",
"end_session_endpoint": "https://id-staging.inex.ge/oauth/logout",
"response_types_supported": ["code"],
"grant_types_supported": ["authorization_code", "refresh_token"],
"subject_types_supported": ["public"],
"id_token_signing_alg_values_supported": ["RS256"],
"code_challenge_methods_supported": ["S256"],
"token_endpoint_auth_methods_supported": ["none", "client_secret_post", "client_secret_basic"],
"scopes_supported": ["openid", "profile", "email", "phone", "inex.parcel"],
"ui_locales_supported": ["ka", "en", "ru"],
"prompt_values_supported": ["none", "login", "select_account", "create"]
}Customer Your app / server INEX ID
| | |
|-- "Sign in" ------>| |
| |-- 302 /oauth/authorize ->|
|------------------- sign in / register ------->|
|<------------- 302 redirect_uri?code&state ----|
|------ code ------->| |
| |-- POST /oauth/token ---->|
| |<-- id_token (sub) -------|
| | |
| |-- POST /integrators/parcels/create
| | receiver.inexUserId = sub