로그인 처리

JAVA

signal시노 2024. 9. 2. 13:05

설명: 레거시 방식은 과거에 주로 사용되던 간단한 로그인 방식입니다. 클라이언트가 서버에 로그인 요청을 보내면 서버는 데이터베이스에서 해당 사용자의 정보를 확인하고, 인증이 완료되면 서버 측에 사용자 정보를 저장해 둡니다.
특징:
- 사용자가 로그인하면 서버에서 세션이나 쿠키를 사용해 로그인 상태를 유지합니다.
- 대부분 서버 측에서 사용자 상태를 관리하며, 이로 인해 서버의 부하가 커질 수 있습니다.
- 보안 측면에서 취약한 점이 있을 수 있으며, 특히 세션 하이재킹 공격에 노출될 수 있습니다.
사용 예: 과거의 웹 애플리케이션, 기본적인 인증이 필요한 내부 시스템 등에서 사용되었습니다.

설명: 세션 방식은 서버가 클라이언트의 로그인 상태를 세션을 통해 관리하는 방식입니다. 클라이언트가 로그인하면 서버는 세션 ID를 생성하고, 이를 클라이언트에게 쿠키로 전달합니다. 클라이언트는 이후 요청에서 이 세션 ID를 사용하여 인증합니다.
특징:
- 서버 상태 기반: 서버 측에서 사용자의 세션 상태를 관리합니다. 세션은 일반적으로 서버 메모리나 데이터베이스에 저장됩니다.
- 쿠키 사용: 클라이언트는 세션 ID가 저장된 쿠키를 브라우저에 저장하여 다음 요청 시 자동으로 보내도록 합니다.
- 보안: 세션 ID가 유출될 경우 세션 하이재킹 공격에 취약할 수 있습니다. 이를 막기 위해 HTTPS와 같은 보안 조치가 필요합니다.
- 단점: 서버에 부하가 많이 걸릴 수 있으며, 확장성이 제한될 수 있습니다.
사용 예: 전통적인 웹 애플리케이션에서 많이 사용되며, 사용자별 상태 관리를 서버에서 처리하는 경우에 적합합니다.

설명: 토큰 방식은 세션 기반 방식과 달리, 서버가 상태를 유지하지 않는 방식으로 인증 정보를 클라이언트가 직접 보관하는 방법입니다. JWT(JSON Web Token)와 같은 토큰을 생성해 클라이언트에게 전달하고, 클라이언트는 이후 모든 요청에 이 토큰을 포함시켜 인증합니다.
특징:
- 서버 무상태성(Stateless): 서버는 사용자의 인증 상태를 유지하지 않으며, 요청 시마다 토큰을 확인합니다. 서버 확장성이 뛰어납니다.
- JWT: 일반적으로 JWT가 많이 사용되며, 토큰에는 클레임(claims)이라는 사용자 정보가 포함될 수 있습니다. 이 정보는 Base64 URL 인코딩 방식으로 인코딩되어 클라이언트와 서버 간에 주고받습니다.
- 보안: 토큰이 유출되면 보안에 취약해질 수 있습니다. 이를 위해 만료 시간을 설정하거나, HTTPS를 사용해 전송 보안을 강화해야 합니다.
- 단점: 토큰의 크기가 클 경우 네트워크 비용이 증가할 수 있으며, 토큰을 강제로 만료시키는 것이 어려울 수 있습니다.
사용 예: RESTful API, 모바일 애플리케이션, 마이크로서비스 아키텍처 등에서 많이 사용됩니다.

설명: OAuth는 제3자 애플리케이션이 사용자의 자원에 접근할 수 있도록 허용하는 인증 및 인가 프로토콜입니다. 사용자는 직접 비밀번호를 제공하지 않고, OAuth 제공자(예: Google, Facebook)를 통해 인증을 수행합니다. OAuth 2.0은 가장 널리 사용되는 버전입니다.
특징:
- 인증 및 인가 분리: OAuth는 인증(Authentication)뿐만 아니라 인가(Authorization)도 처리할 수 있습니다. 이를 통해 사용자는 특정 자원에 대한 접근 권한을 제3자 애플리케이션에 부여할 수 있습니다.
- 토큰 사용: OAuth는 액세스 토큰을 사용해 인증 및 인가를 처리합니다. 액세스 토큰은 일정 기간 동안 유효하며, 리프레시 토큰을 통해 갱신할 수 있습니다.
- 보안: OAuth는 인증을 직접 처리하지 않으므로, 사용자의 비밀번호가 외부 애플리케이션에 노출되지 않습니다. 또한, HTTPS를 통해 보안이 강화됩니다.
- 단점: 구현이 복잡하고, 각 OAuth 제공자마다 구현 방식이 다를 수 있어 설정이 까다로울 수 있습니다.
사용 예: 소셜 로그인(예: Google, Facebook 로그인), API 기반의 서비스에서 사용자의 자원 접근 권한을 위임하는 경우 등에 많이 사용됩니다.