OAuth2.0 és dinamikus kliens regisztráció (a Spring Security OAuth örökölt verem használatával)

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.