Ezzel a bejegyzéssel szeretném megnyitni az IdentityServer4-ről szóló cikkek sorozatát. Az alapfogalmakkal kezdjük.
Jelenleg a legígéretesebb hitelesítési protokoll , míg a hozzáférési engedélyezési protokoll . valósítja meg ezeket a két protokollt. Optimalizálva van a tipikus biztonsági problémák kezelésére.
— ez egy hitelesítési protokoll és szabvány, amely nem biztosít hozzáférést az erőforrásokhoz (Web API), de mivel az engedélyezési protokollra épül , lehetővé teszi a felhasználói profilparaméterek megszerzését, mintha hozzáférést kaptunk volna az erőforráshoz. .
A (JSON Web Token) egy webes szabvány, amely meghatározza a felhasználói adatok JSON formátumban történő, titkosított továbbításának módját.
— ez egy engedélyezési protokoll és szabvány. Lehetővé teszi az alkalmazások számára, hogy hozzáférjenek a védett erőforrásokhoz, például a Web API-hoz.
Nézzük meg a védett erőforráshoz való hozzáférés diagramját, és vizsgáljuk meg az alapvető lépéseket és a használt terminológiát:
A kliens kérvényezi a felhasználótól, hogy engedje meg számára az az ő nevében történő hitelesítést. Ügyfél — ez a kliensalkalmazás, amely a védett erőforrásokhoz fordul a források tulajdonosa nevében. Az erőforrás — ez minden védett szolgáltatásunk .
A felhasználó engedélyezi a kliensalkalmazás számára, hogy az ő nevében végezze el a hitelesítést, például beírja a felhasználónevet és a jelszót. A felhasználónév és jelszó adja meg a kliensalkalmazás engedélyezési jogosultságát. User (forrás tulajdonosa) — program vagy személy, aki hozzáférést biztosíthat a védett erőforrásokhoz, például a felhasználónév (username) és a jelszó (password) megadásával;
A kliensalkalmazás hozzáférési tokent kér a
IdentityServer4a saját információinak megadásával (client_id,client_secret), a felhasználó hitelesítési engedélyének megadásával (username,password) és agrant_typeésscopemegadásával. Ezután az engedélyezési szerver ellenőrzi a kliens és a forrástulajdonos (felhasználónév és jelszó) hitelességét.Az OAuth 2.0 protokoll nemcsak a felhasználó, hanem a védett erőforrásokhoz hozzáférést kivitelező kliensalkalmazás hitelesítését is végzi. Ehhez a protokoll olyan paramétereket ír elő, mint a client_id és client_secret.
client_id — ez a kliensalkalmazás azonosítója, amelyetIdentityServer4az ügyfél információinak keresésére használnak.
client_secret ez a kliensalkalmazás jelszavának megfelelője, és a kliensalkalmazás hitelesítésére használják.IdentityServer4. A kliens titkát csak az alkalmazásnak és az API-nak kell ismernie.. Az eddigiek alapján levonjuk a következtetést, hogy Az IdentityServer4-nek tudnia kell az ügyfeleiről..Ha az alkalmazás hitelesítése megerősített és az engedélyezés érvényes,
IdentityServer4létrehozaccess token-t(hozzáférési token) az alkalmazás számára, és egy opcionális frissítőkulcsot (refresh token). Az engedélyezési folyamat befejeződött. Ha a kérés érvénytelen vagy jogosulatlan, az engedélyezési szerver hibakóddal és a megfelelő hibaüzenettel tér vissza.A kliens alkalmazás adatokat kér a védett Web API-tól, miközben a hozzáférési token-t biztosítja az engedélyezéshez. Ha a szerver válaszkódja , vagy , akkor a hitelesítéshez használt hozzáférési token érvénytelen vagy lejárt.
Ha a token érvényes,
Web APIaz adatok átadásra kerülnek az alkalmazásnak.
Token típusok
A regisztrált IdentityServer4 ügyfelek jogosultak a IdentityServer4 identity-token, hozzáférés-token és frissítés-token kérésére.
- identity token (azonosító token) — a hitelesítési folyamat eredménye. Tartalmazza a felhasználói azonosítót és információkat arról, hogy miként és mikor történik a felhasználó hitelesítése. Saját adatokkal bővíthető.
- access token (hozzáférési token) — a védett API-hoz kerül továbbításra, és azt használja a hozzáférés engedélyezésére a saját adataihoz.
- refresh token (frissítő token) — opcionális paraméter, amelyet az engedélyezési szerver visszaadhat a hozzáférési token kérésére adott válaszban.
Bevezetünk még két fogalmat:
Authenticatation Server Url — a hozzáférési kulcs megszerzésének végpontja. Minden hozzáférési kulcs kérését és megújítását erre az URL-re irányítjuk.
Resource Url — a védett erőforrás URL-je, amelyhez hozzáférést kell kérni, miközben a hozzáférési kulcsot az engedélyezési fejlécben továbbítjuk.
Hozzáférési kulcs kérése
A hozzáférési kulcs kéréséhez a kliens POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols kérést intéz a végponthoz IdentityServer4 a következő fejléc használatával
'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'és a következő paraméterek megadásával:
'grant_type': 'password',
'username': login,
'password': password,
'scope': 'scope',
'client_id': 'client_id',
'client_secret': '{client_secret}'username, password, client_id és client_secret a fentiekben kifejtettek. Vizsgáljunk meg további paramétereket:
grant_type — a grant type or authorization grant type. The authorization grant type depends on the method of authorization request used by the application, as well as the types of grants supported by the API. In our case, it will be equal to password, which according to the specification OAuth 2.0 corresponds to the resource owner's access credentials grant (authorization by login and password).
Protokoll OAuth 2.0 defines the following types of grants that require mandatory interaction with users:
- authorization code. It is one of the most common types of authorization grants, as it is well-suited for server-side applications, where the application's source code and client secret are not accessible to outsiders;
- implicit. The implicit authorization grant type is used by mobile and web applications, where the confidentiality of the client secret cannot be guaranteed;
And the grant types that can be performed without interactive user interaction:
- resource owner credentials.. This type of authorization should only be used when the client application is trusted by the user, and the user is comfortable entering their login and password. This type of authorization should only be used when other options are not available. This type of authorization is convenient for corporate clients who have already used user credentials within their system and want to switch to
OAuth 2.0. - client credentials. These are used when the application accesses the API. This can be useful, for example, when the application wants to update its registration information on the service or redirect URI, or access other information stored in the application account on the service through the service API.
scope — ez nem kötelező paraméter. Meghatározza a láthatóság terjedelmét. Az a hozzáférési token, amelyet a szerver visszaad, csak azokhoz a szolgáltatásokhoz biztosít hozzáférést, amelyek ebbe a terjedelembe tartoznak. Azaz több szolgáltatást egyetlen terjedelem alá vonhatunk, és ha a felhasználó hozzáférési kulcsot kap ehhez a terjedelemhez, akkor hozzáférést kap mindezekhez a szolgáltatásokhoz. A terjedelem korlátozhatja az engedélyezési jogokat is (például olvasási vagy írási hozzáférés).
Forrás: habr.com
