streamalism.org

1. Bemutatkozás

Ebben az oktatóanyagban dinamikus ügyfélregisztrációt fogunk előkészíteni az OAuth2.0 alkalmazással. Az OAuth2.0 egy engedélyezési keretrendszer, amely korlátozott hozzáférést biztosít a felhasználói fiókokhoz egy HTTP szolgáltatáson keresztül. Az OAuth2.0 kliens az az alkalmazás, amely hozzáférni akar a felhasználó fiókjához. Ez az ügyfél lehet külső webalkalmazás, felhasználói ügynök vagy csak natív kliens.

A dinamikus kliens regisztráció elérése érdekében a hitelesítő adatokat az adatbázisban fogjuk tárolni a hardkódolt konfiguráció helyett. A kiterjeszteni kívánt alkalmazást eredetileg a Spring REST API + OAuth2 oktatóanyagban írták le.

jegyzet: ez a cikk a Spring OAuth örökölt projektet használja.

2. Maven-függőségek

Először a következő függőségeket állítjuk be:

 org.springframework.boot spring-boot-starter-web org.springframework spring-jdbc org.springframework.security.oauth spring-security-oauth2 

Ne feledje, hogy használjuk tavasz-jdbc mert egy DB-t fogunk használni az újonnan regisztrált felhasználók jelszavakkal történő tárolására.

3. OAuth2.0 kiszolgáló konfigurálása

Először konfigurálnunk kell az OAuth2.0 hitelesítő kiszolgálónkat. A fő konfiguráció a következő osztályba esik:

@Configuration @PropertySource ({"classpath: persistence.properties"}) @EnableAuthorizationServer nyilvános osztály OAuth2AuthorizationServerConfig kiterjeszti a AuthorizationServerConfigurerAdapter {// config}

Van néhány fontos dolog, amit konfigurálnunk kell; kezdjük ClientDetailsServiceConfigurer:

A @Orride public void configure (végső ClientDetailsServiceConfigurer ügyfelek) a (z) {clients.jdbc (dataSource ()) // ...} kivételt dobja

Ez biztosítja, hogy kitartást használunk az ügyféladatok megszerzéséhez.

Természetesen állítsuk be ezt a szabványos adatforrást:

@Bean public DataSource dataSource () {DriverManagerDataSource dataSource = új DriverManagerDataSource (); dataSource.setDriverClassName (env.getProperty ("jdbc.driverClassName")); dataSource.setUrl (env.getProperty ("jdbc.url")); dataSource.setUsername (env.getProperty ("jdbc.user")); dataSource.setPassword (env.getProperty ("jdbc.pass")); return dataSource; }

Tehát most az alkalmazásunk az adatbázist regisztrált kliensek forrásaként fogja használni, a tipikus memóriakártyák helyett.

4. A DB rendszer

Most definiáljuk az SQL struktúrát az OAuth kliensek tárolásához:

tábla létrehozása oauth_client_details (ügyfél_azonosító VARCHAR (256) ELSŐKULCS, erőforrás_azonosítók VARCHAR (256), ügyfél_secret VARCHAR (256), hatókör VARCHAR (256), jogosult_grant_típusok VARCHAR (256), web_szerver_redirect__vezetési_támogatás (V6) , refresh_token_validity INTEGER, további_információk VARCHAR (4096), automatikus jóváhagyás VARCHAR (256));

A legfontosabb mezők a oauth_client_details a következőkre kell összpontosítanunk:

• Ügyfélazonosító - az újonnan regisztrált ügyfelek azonosítójának tárolása
• client_secret - az ügyfelek jelszavának tárolásához
• access_token_validity - ami azt jelzi, hogy az ügyfél továbbra is érvényes-e
• hatóság - annak jelzése, hogy milyen szerepkörök engedélyezettek egy adott ügyfélnél
• hatálya - megengedett műveletek, például állapotok írása a Facebook-on stb.
• Author_grant_types, amely információt nyújt arról, hogy a felhasználók hogyan tudnak bejelentkezni az adott klienshez (példánkban ez egy jelszóval ellátott űrlap bejelentkezés)

Felhívjuk figyelmét, hogy minden ügyfélnek egy az egyhez viszonya van a felhasználókkal, ami természetesen ezt jelenti több felhasználó használhat egyetlen klienst.

5. Tartsunk fenn néhány ügyfelet

Az SQL séma definiálásával végre létrehozhatunk néhány adatot a rendszerben - és alapvetően meghatározhatunk egy klienst.

A következőket fogjuk használni adatok.sql parancsfájl - amely a tavaszi rendszerindítást alapértelmezés szerint futtatja - a DB inicializálásához:

INSERT INTO oauth_client_details (kliens_azonosító, kliens_ titok, hatókör, engedélyezett_grant_típusok, webszerver_redirect_uri, jogosultságok, hozzáférés_meghívás érvényessége, refresh_token_validitás, további_információ, automatikus jóváhagyás) VALUES ("fooClientIdPassword", "password", "password", "password", "titkos", "titkos", "titkos", "titkos", , null, 36000, 36000, null, true);

A legfontosabb mezők leírása oauth_client_details az előző szakaszban található.

6. Tesztelés

A dinamikus kliens regisztráció teszteléséhez mindkettőt futtatnunk kell spring-security-oauth-server és spring-security-oauth-resource a 8081-es és a 8082-es porton.

Most végre írhatunk néhány élő tesztet.

Tegyük fel, hogy regisztráltuk az ügyfelet azonosítóval fooClientIdPassword, amely hozzáférhet a fóniák olvasásához.

Először megpróbálunk hozzáférési tokent szerezni az Auth Server-től egy már definiált ügyfél használatával:

@Test public void givenDBUser_whenRevokeToken_thenAuthorized () {String accessToken = iegūtAccessToken ("fooClientIdPassword", "john", "123"); assertNotNull (accessToken); }

És itt van az Access Token megszerzésének logikája:

privát karakterlánc getAccessToken (String clientId, String felhasználónév, String jelszó) {Map params = new HashMap (); params.put ("grant_type", "jelszó"); params.put ("client_id", clientId); params.put ("felhasználónév", felhasználónév); params.put ("jelszó", jelszó); Válaszválasz = RestAssured.given (). Auth (). Preemptive () .basic (clientId, "secret"). És (). (). Params (params) .when () .post ("// localhost: 8081 / spring-security-oauth-server / oauth / token "); return response.jsonPath (). getString ("access_token"); }

7. Következtetés

Ebben az oktatóanyagban megtanultuk, hogyan lehet korlátlan számú ügyfelet dinamikusan regisztrálni az OAuth2.0 keretrendszerrel.

Ennek az oktatóanyagnak a teljes megvalósítása megtalálható a GitHub-on - ez egy Maven-alapú projekt, ezért könnyen importálhatónak és futtathatónak kell lennie.

Felhívjuk figyelmét, hogy a teszteléshez ügyfeleket kell hozzáadnia a DB-be, és hogy a .emlékül() A config már nem lesz érvényes. Ha a régit szeretné használni.emlékül() config, van egy második fájl, amely konfigurációt tartalmaz keménykódolt kliensekkel.