Abdullah Kökbıyık
Ahmet Musa Çatak
Mustafa Emre Başar
Oğuz Ok

API Key (API Anahtarı) ve Session-Based Authentication (Oturum Tabanlı Kimlik Doğrulama)

API Key (API Anahtarı) ve Session-Based Authentication (Oturum Tabanlı Kimlik Doğrulama)

API Key Authentication

REST API (Representational State Transfer Application Programming Interface - Temsili Durum Transferi Uygulama Programlama Arayüzü) geliştirmesi sırasında güvenlik önemli bir role sahiptir. Uygulamada bulunan endpoint’lere (uç nokta) yalnızca gerekli yetkilere sahip kullanıcıların erişmesi gerekir. Güvenli olmayan bir REST API, kimlik doğrulama eksikliği nedeniyle yetkisiz kişilerin sisteme giriş yapmasına, yetkilendirme açıkları nedeniyle kullanıcıların erişim sınırlarını aşmasına yol açabilir. Ayrıca şifrelenmemiş veri iletimi, saldırganların hassas bilgileri ele geçirmesine imkân tanıyabilir. Bu tür güvenlik açıkları sistemdeki hassas verilere ve kritik işlemlere izinsiz erişim sağlanmasına neden olabilir. Bu nedenle API güvenliğine önem verilmesi gerekir.

Spring Security (Spring Güvenlik), REST API’larımızın güvenliğini sağlamak için çeşitli mekanizmalar sunar [2]. Bunlardan biri API key’dir. API key’i, bir istemcinin API çağrılarını yaparken sağladığı bir token’dır (belirteç).

Güvenilir bir yapıya sahip Spring uygulaması oluştururken Spring Boot API’ını, API Key’i ve Secret (Gizli) kullanarak güvence altına almak önemlidir. Bu sayede uygulamada bulunan endpoint’lere sadece yetkili kullanıcıların erişmesi sağlanır.

API Key: Yetkili kullanıcılara veya uygulamalara atanan benzersiz bir tanımlayıcıdır. Her API isteğiyle beraber gönderilir ve genel bir kimlik bilgisi görevi görür. [API client’ını (istemci) API’ye tanımlayan token]

Genelde API Key isteğin header (başlık) bölümüne eklenir ve SSL (Secure Sockets Layer – Güvenli Yuva Katmanı) kullanılarak aktarım sırasında korunabilir. Ancak API Key’lerin güvenliği sadece iletimle sınırlı kalmamalıdır. İstemcide güvenli saklama yöntemleri kullanılmalı, düz metin olarak depolanmamalıdır. Ayrıca API Key’lerin belirli bir süre sonra otomatik olarak geçersiz hale gelmesi (expiration) ve düzenli olarak yenilenmesi güvenliği artıran önemli önlemler arasındadır.

Secret: API Key ile ilişkili özel, hassas bir veridir. Genellikle isteğin geçerliliğini doğrulamak için imza oluşturma amacıyla kullanılır.

Spring uygulamamızı API Key ve Secret kullanarak korumak için yapılması gereken adımlar:

Dependencies (Bağımlılıklar)

1
2
3
4
5
6

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

[1]

Authentication Filter (Kimlik Doğrulama Filtreleri)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

@Component
@RequiredArgsConstructor
public class AuthenticationFilter extends GenericFilterBean {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String requestURI = httpRequest.getRequestURI();

        if (requestURI.startsWith("/protected/")) {
            try {
                Authentication authentication = AuthenticationService.getAuthentication(httpRequest);
                SecurityContextHolder.getContext().setAuthentication(authentication);
            } catch (Exception exp) {
                HttpServletResponse httpResponse = (HttpServletResponse) response;
                httpResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
                httpResponse.setContentType(MediaType.APPLICATION_JSON_VALUE);
                PrintWriter writer = httpResponse.getWriter();
                writer.print(exp.getMessage());
                writer.flush();
                writer.close();
            }
        }
        filterChain.doFilter(request, response);
    }
}
  • AuthenticationFilter class’ında bulunan doFilter fonksiyonu, HTTP isteklerini kesip istek daha fazla ilerlemeden önce kimlik doğrulama kontrollerini yapmak için kullanılır.
  • Gelen HTTP isteği ve geri gönderilecek yanıtla etkileşim kurmak için parametre olarak alınan ServletRequest, ServletResponse kullanılır.
  • FilterChain, ilgili isteğin ve yanıtın zincirdeki bir sonraki filtreye ilerlemesi için kullanılır.

if (requestURI.startsWith("/protected/")) →

  • Fonksiyon, istek URI’sinin “/protected/” ile başlayıp başlamadığını kontrol eder. Eğer “/protected/” ile başlıyorsa istek korumalı bir kaynağa erişmeye çalışıyor demektir ve kimlik doğrulama işlemlerinin yapılması gerekir.

  • İsteğin kimliğini doğrulamak için AuthenticationService.getAuthentication(httpRequest) çağrılır. Buradan dönen Authentication nesnesi daha sonra saklanmak üzere SecurityContextHolder’a atanır.

  • Kimlik doğrulama işlemi sırasında bir hata oluşursa, HTTP yanıt durumu 401 (Unauthorized) olarak ayarlanır. Ayrıca yanıtın içerik türü JSON olarak belirlenir ve hata mesajı yanıta eklenir.

  • Son olarak isteğin kimliği doğrulanmış olsun ya da olmasın, filterChain.doFilter(request, response) çağırılarak isteğin ve yanıtın zincirdeki bir sonraki filtreye aktarılması sağlanır.

Authentication Service (Kimlik Doğrulama Servisi)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class AuthenticationService {

    //@Value("${api.key}")
    private static final String API_AUTH_TOKEN_HEADER_NAME = "AUTH-API-KEY";

    //@Value("${api.secret}")
    private static final String API_AUTH_TOKEN = "AUTH-API-SECRET";

    public static Authentication getAuthentication(HttpServletRequest request) {
        String apiKey = request.getHeader(API_AUTH_TOKEN_HEADER_NAME);
        if (apiKey == null || !apiKey.equals(API_AUTH_TOKEN)) {
            throw new BadCredentialsException("Invalid Authentication API Key");
        }

        return new ApiKeyAuthentication(apiKey, AuthorityUtils.NO_AUTHORITIES);
    }
}
  • AuthenticationService sınıfı, API key’ine bağlı olarak HTTP isteklerinin kimlik doğrulamasından sorumludur.
  • getAuthentication fonksiyonu, gelen HTTP isteğinin kimliğini doğrulamak için kullanılır.
  • Fonksiyon API key’ini istek header’ından alır. Header alanının adı API_AUTH_TOKEN_HEADER_NAME sabitinde saklıdır.
  • Yöntem daha sonra API key’inin null olup olmadığını veya API_AUTH_TOKEN sabitinde saklanan beklenen API key ile eşleşip eşleşmediğini kontrol eder. Bu koşullardan herhangi biri doğruysa yöntem, API key’in geçersiz olduğunu belirten bir mesajla birlikte bir BadCredentialsException fırlatır.
  • API key’i geçerliyse, fonksiyon API key ve boş bir yetkili listesi içeren yeni bir ApiKeyAuthentication nesnesi oluşturur. Bu nesne, kimliği doğrulanmış asıl kişiyi temsil eder. Fonksiyon daha sonra bu nesneyi döndürerek kimlik doğrulamanın başarılı olduğunu belirtir.
  • AuthenticationService sınıfı ve getAuthentication fonksiyonu tipik olarak Spring Security yapılandırmasındaki bir filtre veya interceptor’da kullanılır. Filtre veya interceptor, gelen her HTTP isteğinin kimliğini doğrulamak için bu fonksiyonu çağırır. Kimlik doğrulama başarılı olursa, isteğin devam etmesine izin verilir. Kimlik doğrulama başarısız olursa istek reddedilir ve bir hata cevabı dönülür.

API Key Authentication Object (API Anahtarı ile Kimlik Doğrulama Nesnesi)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class ApiKeyAuthentication extends AbstractAuthenticationToken {
    private final String apiKey;

    public ApiKeyAuthentication(String apiKey, Collection<? extends GrantedAuthority> authorities) {
        super(authorities);
        this.apiKey = apiKey;
        setAuthenticated(true);
    }

    @Override
    public Object getCredentials() {
        return null;
    }

    @Override
    public Object getPrincipal() {
        return apiKey;
    }
}
  • Kimlik doğrulama için kullanılan API key’i temsil eden private final apiKey tanımlaması yapılır.
  • Constructor, AbstractAuthenticationToken’in constructor’ını authorities parametresi ile çağırır ve apiKey değişkeninin atamasını yapar. Ayrıca setAuthenticated fonksiyonunu true parametresi ile çağırarak kimlik doğrulamanın başarılı olduğunu belirtir.
  • ApiKeyAuthentication sınıfı, bir API key kullanan kimliği doğrulanmış bir kişiyi temsil eden özel bir kimlik doğrulama token’idir.

Security Configuration (Güvenlik Yapılandırması)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

@Configuration
@EnableWebSecurity
public class SecurityConfiguration {

    private final AuthenticationFilter authenticationFilter;

    public SecurityConfiguration(AuthenticationFilter authenticationFilter) {
        this.authenticationFilter = authenticationFilter;
    }

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .cors().disable()
                .csrf().disable()
                .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .formLogin().disable()
                .securityMatcher("/**")
                .authorizeHttpRequests(registry -> registry
                        .requestMatchers(AntPathRequestMatcher.antMatcher("/public/**")).permitAll()
                        .requestMatchers(AntPathRequestMatcher.antMatcher("/protected/**")).authenticated()

                )
                .addFilterBefore(authenticationFilter, UsernamePasswordAuthenticationFilter.class)
                .build();
    }
}

[2]

SessionCreationPolicy.STATELESS →

  • Spring Security bir HTTP oturumu oluşturmaz ve oturumda herhangi bir kimlik doğrulama verisi veya oturumla ilgili bilgi depolamaz.
  • Her istek birbirinden bağımsız olarak kabul edilir ve client her istekle birlikte kimlik doğrulama bilgilerini (örn. token) eklemelidir.
  • JWT gibi oturum bilgisi olmayan kimlik doğrulama mekanizmaları, token’in gerekli tüm kimlik doğrulama bilgilerini içerdiği ve sunucunun her istekte token’i doğruladığı bu senaryoda yaygın olarak kullanılır.
  • Sunucunun istekler arasında herhangi bir oturum durumunu saklaması gerekmediği RESTful API’ler için uygundur.

.formLogin().disable() →

  • Form tabanlı kimlik doğrulama, kullanıcıya kimlik doğrulaması için bir oturum açma formunun (tipik olarak kullanıcı adı ve parola alanları) sunulduğu bir mekanizmadır.
  • Spring Security’ye form tabanlı kimlik doğrulamayı kullanmayacağını belirtiyoruz.
  • Client’ın oturum açma formu yerine token’ler veya başka araçlar kullanarak kimlik doğrulaması yaptığı bir API oluşturulduğunda kullanılır.

.requestMatchers(AntPathRequestMatcher.antMatcher("/public/**")).permitAll() →

  • .permitAll(): Bu yöntem ile belirtilen istek ucuna kısıtlanmamış şekilde erişim sağlanır. Kimliği doğrulanmış olsun ya da olmasın, herhangi bir kullanıcı bu yapı ile eşleşen URL’lere herhangi bir kısıtlama olmaksızın erişebilir.

.requestMatchers(AntPathRequestMatcher.antMatcher("/protected/**")).authenticated()

  • .authenticated(): Bu yöntem belirtilen uç ile eşleşen URL’lere erişen kullanıcıların kimliğinin doğrulanmasını gerektirir. Başka bir deyişle, erişim yalnızca kimliğini başarıyla doğrulayan kullanıcılara verilir.

.addFilterBefore(authenticationFilter, UsernamePasswordAuthenticationFilter.class)

  • Kendi tanımladığımız filter’ı SecurityFilterChain‘e eklemek için kullanılır.

API Key Authentication Controller (API Anahtarı ile Kimlik Doğrulama Denetleyicisi)

1
2
3
4
5
6
7
8
9
10
11
12
13

@RestController
public class ApiKeyAuthenticationController {

    @GetMapping("/public/goodbye")
    public String goodbye() {
        return "Public Goodbye, World! This is a public endpoint.";
    }
    
    @GetMapping("/protected/hello")
    public String hello() {
        return "Protected Hello, World! This is a protected endpoint.";
    }
}
  • RestController sınıfımız, hello ve goodbye adında belirli URL’lerdeki GET istekleriyle eşleşen iki fonksiyon içerir.
  • goodbye fonksiyonu “/public/goodbye” URL’i ile eşleştirilir. Bu uç nokta herkese açıktır ve herhangi bir kimlik doğrulaması gerektirmez.
  • hello fonksiyonu “/protected/hello” URL’i ile eşleştirilir. Ancak bu uç nokta korumalıdır ve kimlik doğrulaması gerektirir.
  • Özetle, ApiKeyAuthenticationController sınıfı biri public diğeri protected olmak üzere iki uç noktası olan bir REST Controller’dır. Korumalı uç nokta, kimlik doğrulama için bir API key gerektirir.
1
2
3
4

    //200 OK. The request has succeeded.
    /* curl --location --request GET 'http://localhost:8080/public/goodbye' */
    /* Invoke-WebRequest -Uri 'http://localhost:8080/public/goodbye' -Method GET */


1
2
3
4
5
6
7
8

    //401 Unauthorized. The request has not been applied because it lacks valid authentication credentials for the target resource.
    /* curl --location --request GET 'http://localhost:8080/protected/hello' */
    /* Invoke-WebRequest -Uri 'http://localhost:8080/protected/hello' -Method GET */

    //200 OK. The request has succeeded.
    /* curl --location --request GET 'http://localhost:8080/protected/hello' \ --header 'AUTH-API-KEY: AUTH-API-SECRET' */
    /* Invoke-WebRequest -Uri 'http://localhost:8080/protected/hello' -Headers @{ 'AUTH-API-KEY' = 'AUTH-API-SECRET' }  */

Bu uç noktaları test etmek için yukarıda bulunan curl ve PowerShell komutları çalıştırılabilir. Korumalı uç nokta için olan komutta API key içeren bir başlık verilmelidir.

Session Based Authentication (Oturum Tabanlı Kimlik Doğrulama)

  • Yetkilendirme yapan bir sisteme sahip olduğumuzda, bir sonraki adım kullanıcıların oturumlarını yönetmektir. Bu, kullanıcıların kimlik doğrulamasını bir kez yapmalarını ve ardından oturumlarının süresi boyunca kimlik doğrulamasını tekrar yapmamalarını sağlar. Bu, kullanıcıların her sayfayı ziyaret ettiklerinde kimlik doğrulaması yapmaları gerekmeyeceği anlamına gelir. Yani sunucuya yapılan her istekte kimlik doğrulaması yapmak zorunda kalmayız.

  • Bu noktada Oturum Tabanlı Kimlik Doğrulama (Session Based Authentication) devreye girer. Bu, kullanıcıların oturumlarını yönetmek için sunucu tarafında bir oturum yöneticisi kullanır. Bu oturum yöneticisi, kullanıcıların oturumlarını yönetmek için bir kimlik doğrulama mekanizması sağlar.

Öncelikle bu konudaki terimlere açıklık getirelim;

  • Oturum (Session): Kullanıcıyla belirli bir süre ilişkilendirilen, sunucuda tutulan durum bilgisi taşıyan bir veri yapısıdır. Kullanıcının durumunu istekler boyunca takip edebilmek için kullanıcı bilgilerini, tercihlerini ve diğer alakalı detayları içerir.

  • Oturum Kimliği (Session ID): Oturumun benzersiz ve rastgele bir kimliğidir. Bu kimlik, sunucu tarafında oturumun kimliğini belirlemek için kullanılır. Oturum kimliği, kullanıcıya özgüdür ve kullanıcı oturumunu belirlemek için kullanılır.

  • Çerez (Cookie): Kullanıcının site üzerindeki tercihlerini hatırlamak, kullanıcı bilgilerini saklamak, oturum bilgilerini korumak için depolanan küçük bir metin dosyasıdır. Bu dosya, kullanıcı bilgilerini saklamak için kullanılır. Kullanıcı bilgilerini, istemci tarafında saklamak için kullanılır ve her istekte sunucuya gönderilir. Bu, kullanıcı bilgilerinin her istekte sunucuya gönderilmesini sağlar.

  • Oturum Deposu (Session Store): Oturum bilgilerini saklamak için kullanılan bir veri deposudur. Bu veri deposu, sunucu tarafında oturum bilgilerini saklamak için kullanılır. Oturum bilgilerini, sunucu tarafında saklamak için kullanılır.

Oturum Tabanlı Kimlik Doğrulama (Session Based Authentication) nasıl çalışır?

  1. Kullanıcı Girişi: Kullanıcı, kullanıcı adı ve şifre gibi kimlik bilgilerini uygulamaya gönderir.

  2. Kimlik Doğrulama: Sunucu, kullanıcı kimlik bilgilerini doğrular.

  3. Oturum Oluşturma: Sunucu, kullanıcıya özgü bir oturum kimliği oluşturur ve bu oturum kimliğini kullanıcıya gönderir. Bu oturum kimliği, istemci tarafında bir çerez içerisinde saklanır.

  4. Oturum Doğrulama: İtemci her istekte oturum kimliğini gönderir, Sunucu,oturum kimliğini kontrol eder ve kullanıcının oturumunun geçerli olup olmadığını kontrol eder.

  5. Yetkilendirme: Sunucu, kullanıcının oturumunun geçerli olduğunu doğrularsa, kullanıcıya yetkilendirme yapar.

  6. Oturum Sonlandırma: Kullanıcı oturumu sonlandırmak istediğinde, sunucu oturum kimliğini geçersiz kılar.

Şekil 1’de örnek bir oturum tabanlı kimlik doğrulama görülmektedir.



Şekil 1. Oturum Tabanlı Kimlik Doğrulama Yapısı

Oturum Tabanlı Kimlik Doğrulama (Session Based Authentication) ve Spring Boot

  • Bir Spring Boot uygulamasına Spring Security bağımlılığını eklediğimizde oturum tabanlı kimlik doğrulama mekanizması otomatik olarak devreye girer. Spring Security, oturum tabanlı kimlik doğrulama mekanizmasını sağlamak için bir oturum yöneticisi kullanır. Bu oturum yöneticisi, kullanıcıların oturumlarını yönetmek için bir kimlik doğrulama mekanizması sağlar.

  • Spring Security bize user kullanıcı adı için program ayağa kalkarken bir şifre üretir. Bu şifre konsolda gösterilir. Bu şifre ile giriş yapabiliriz. Giriş yaptıktan sonra ilgili porta ait bir çerez üretildiğini şekil 2’deki gibi görüntüleyebiliriz. Ancak “default” kullanıcı adı ve şifreyi kullanmak büyük güvenlik riskleri oluşturabileceğinden, özelleştirilmiş bir yapılandırma kullanılması önemlidir.



Şekil 2. Oturum Tabanlı Kimlik Doğrulama Spring Boot

  • Ancak bu kullanımda, oturum bilgileri SecurityContext içerisinde tutulmaktadır ve sunucu sonlandığında ilgili oturum bilgilerini kaybederiz. Sunucu tekrar başlattığımızda çerezde saklanan oturum kimliği sunucu için bir şey ifade etmediğinden tekrar giriş yapılması gerekir.

  • Oturum bilgisini sunucuya ait bir context’te tutmanın bir diğer negatif yanıda yükü azaltmak için paralel çalışan birden fazla sunucu kullanmak istediğimizde, sisteme bir giriş yapıldığında oturum bilgisini bir sunucunun yerelinde saklamış oluruz. Ancak ilerleyen istekler yük dengeleyici tarafından başka bir sunucuya yönlendirildiğinde, bu sunucu oturum bilgisine erişemeyeceğinden, kullanıcı tekrar giriş yapmak zorunda kalır. Şekil 3’te bu yapıyı görebiliriz.

  • Bu noktada Redis, MongoDB, MySQL gibi veri depolarını kullanarak oturum bilgilerini saklayabiliriz. Bu depolar, sunucu tarafında oturum bilgilerini saklamak için kullanılır. Oturum bilgilerini, sunucu tarafında saklamak için kullanılır. [4], [5], [6]



Şekil 3. Oturum Tabanlı Kimlik Doğrulamada Oturum Bilgileri

Session Based Authentication (Oturum Tabanlı Kimlik Doğrulama) ve Spring Security (Spring Güvenliği)

  • Spring için Spring Session bize bu veri depoları ile kolayca entegre bir şekilde oturum bilgilerini saklamamızı sağlar. [3]

  • Uygulamamıza Spring Session ve Data Redis bağımlılıklarını eklediğimizde, varsayılan olarak kullanılan tomcat oturumu yerine Spring Session tarafından yönetilen oturumlar kullanılır. Bu oturumlar, Redis veri deposunda saklanır. Bu sayede sunucu tarafında oturum bilgilerini saklamak için Redis veri deposunu kullanabiliriz. Böylelikle sunucudan bağımsız olarak çalışan bir depoda bilgileri sakladığımız için sunucu devre dışı kaldığında veya paralel çalışan sunuculara geçtiğimizde oturum bilgilerini kaybetmeyiz. İlgili session bilgileri şekil 4’te görülmektedir.



Şekil 4. Oturum Tabanlı Kimlik Doğrulama Spring Session

Spring Boot uygulamanıza Spring Session eklediğinizde, otomatik olarak Spring Security ile entegre olarak oturum tabanlı kimlik doğrulamayı etkinleştirir. Bu nasıl oluyor?

Entegrasyon Mekanizması

  • Spring Session Bağımlılığı Projenize Spring Session bağımlılığını eklediğinizde, otomatik olarak SessionManagementFilter adında bir oturum yönetim filtresi yapılandırır.

  • Oturum Filtresi Entegrasyonu Bu filtre gelen istekleri karşılar ve istekle ilişkili geçerli bir oturum olup olmadığını almaya çalışır. Genellikle SESSION adlı bir çerezde saklanan oturum kimliğini arar.

  • Güvenlik Konteks Yönetimi Geçerli bir oturum bulunursa, Spring Security, kimliği doğrulanmış kullanıcı hakkında bilgi (örneğin, kullanıcı adı, roller) içeren ilişkili SecurityContext nesnesini alır.

  • Yetkilendirme Kararları Spring Security daha sonra kullanıcının rolleri ve izinlerine göre yetkilendirme kararları vermek için SecurityContext içindeki bilgileri kullanır.

Spring Session, oturum oluşturma, depolama ve yönetimi dahil olmak üzere oturum yönetimi altyapısını sağlar. Spring Security, geçerli bir oturum bulunduğunda mevcut oturum bağlamını kullanarak bu altyapıdan yararlanır. Bu entegrasyon, oturum tabanlı kimlik doğrulama için kurulumu basitleştirir ve minimum ek konfigürasyon gerektirir.

Bu altyapının bir diğer önemli avantajı Redis gibi yüksek performanslı veri depolarıyla entegrasyonudur. Redis, düşük gecikme süresi ve yüksek okuma/yazma performansı sayesinde oturum verilerini merkezi bir konumda hızlı ve güvenilir bir şekilde saklar. Bu sayede:

  • Dağıtık Sistemlerde Ölçeklenebilirlik: Oturum verileri sunucu bağımsız hale gelir bu da birden fazla sunucu arasında oturum paylaşımını ve yük dengelemesini mümkün kılar.
  • Yük Dengeleme: Oturum verilerinin merkezi depolanması, artan trafik durumlarında sunucular arası dengenin sağlanmasına katkıda bulunur. Böylece sistemdeki yük daha etkili bir şekilde dağıtılarak performans artışı sağlanır.
  • Hızlı Erişim: Redis’in bellek içi (in-memory) veri saklama özelliği, oturum verilerine erişimi hızlandırır ve sistemin genel performansını olumlu yönde etkiler. Bu yapılandırma, özellikle yüksek trafikli uygulamalarda oturum yönetiminin sorunsuz bir şekilde işlemesini sağlayarak kullanıcı deneyimini artırır ve sistemin yüksek erişilebilirlik ile ölçeklenebilirlik gereksinimlerini karşılamada kritik rol oynar.

Örneğin aşağıdaki kod parçası, Spring Session için oluşturulacak çerez düzenlenebilir.

1
2
3
4
5
6
7

@Bean
public CookieSerializer cookieSerializer() {
	DefaultCookieSerializer serializer = new DefaultCookieSerializer();
	serializer.setCookieName("CUSTOM_SESSION_ID");
	serializer.setCookieMaxAge("3000");
	return serializer;
}
  • Oluşan çerez şekil 5’teki gibi istediğimiz isimde ve sürede oluşturulmuştur.



Şekil 5. Oturum Tabanlı Kimlik Doğrulama Özel Oturum

Eklenen çerezin özelliklerini properties dosyası ile yönetmek de mümkündür, örneğin çerezin yaşam süresi aşağıdaki şekilde application.properties dosyasına eklenerek ayarlanabilir.

1

server.servlet.session.timeout = 30s

Böylelikle 30 saniye sonrasında kullanıcıdan tekrar giriş yapması istenecektir.

Sonuç

API Key Authentication (API Anahtarı ile Kimlik Doğrulama) ve Session-Based Authentication (Oturum Tabanlı Kimlik Doğrulama) yaklaşımları uygulamanızın güvenlik gereksinimlerini karşılamak için etkili yöntemler sunar. API Key Authentication, daha hafif ve stateless (durumsuz) yapısı sayesinde özellikle servisler arası iletişim ve basit entegrasyon senaryolarında tercih edilebilir. Bu yöntemde bağımlılıklar, filtreleme, servis katmanı ve özel nesneler aracılığıyla API key’lerin doğrulanması ve yönetimi gerçekleştirilir.

Öte yandan Session-Based Authentication, kullanıcı bazlı oturum yönetimi gerektiren senaryolarda güçlü bir çözüm sunar. Spring Boot ve Spring Security ile entegrasyonu sayesinde, oturum yönetimi altyapısı otomatikleştirilir. Bu da daha güvenli ve ölçeklenebilir bir yapı oluşturulmasına yardımcı olur. Özellikle Redis gibi bellek içi veri depolama çözümleriyle desteklendiğinde, oturum yönetiminde düşük gecikme süreleri ve yüksek performans elde edilir.

Sonuç olarak uygulamanın gereksinimleri, kullanım senaryoları ve ölçeklenebilirlik ihtiyaçlarına göre doğru yaklaşımın seçilmesi kritik önem taşımaktadır. API Key Authentication daha basit ve hafif işlemler için ideal bir seçenekken Session-Based Authentication karmaşık kullanıcı oturumlarının yönetiminde ve dağıtık sistemlerde daha etkili bir çözüm sunar.

Serinin bir sonraki yazısına Multi-Factor Authentication, Custom Authentication ve CAS Yaklaşımları adresinden ulaşabilirsiniz.

*Bu yazının hazırlanmasında katkı sağlayan teknik gözden geçirme için Rabia Nur ÖNAL’a ve Ahmet Burak KAPLAN’a, içerik düzenlemelerinde destek sunan Kübra ERTÜRK’e teşekkür ederiz. Sağladıkları geri bildirimler, yazının hem teknik doğruluğunu hem de okunabilirliğini artırmada önemli rol oynamıştır.

Kaynakça

[1] Spring Boot Starter Security, URL: https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-security (Erişim zamanı; Şubat, 12, 2024).

[2] Spring Security Reference, URL: https://docs.spring.io/spring-security/reference/ (Erişim zamanı; Şubat, 15, 2024).

[3] Spring Session Reference, URL: https://docs.spring.io/spring-session/reference/ (Erişim zamanı; Şubat, 20, 2024).

[4] Redis, URL: https://redis.io/ (Erişim zamanı; Nisan, 10, 2024).

[5] MongoDB, URL: https://www.mongodb.com/ (Erişim zamanı; Nisan, 11, 2024).

[6] MySQL, URL: https://www.mysql.com/ (Erişim zamanı; Nisan, 11, 2024).