[Winter Blog Challenge] 로그인 인증 방식 (Chapter Memer 전지연)

안녕하세요! GDGoC Chapter Member 전지연입니다.

저는 이번 글에서 로그인 인증 방식 4가지를 간단히 소개하고자 합니다.

1. 세션 방식

Session은 서버 측에서 사용자 상태를 유지하고 인증 정보를 저장하는 방식입니다.

사용자가 서버에 접속하면 서버는 사용자의 인증 정보를 세션(Session)에 저장하고, 해당 세션 ID를 클라이언트에 전달합니다. 이후 클라이언트가 서버에 요청을 보낼 때 받은 세션 ID를 함께 전송하여 서버가 해당 사용자의 세션 정보를 확인할 수 있게 합니다.

Session의 장점

• 인증 정보를 서버 측에서 관리한다는 점에서 보안성이 높습니다
• 서버 측에서 인증 정보를 관리하므로 클라이언트에서 인증 정보를 별도로 관리할 필요가 없습니다.

Session의 단점

• 사용자가 많아지면 세션 관리로 인해 서버의 부하가 증가합니다
• 서버에서 세션 정보를 유지하기 때문에 서버의 확장성이 떨어집니다

 

2. 쿠키 방식

쿠키는 HTTP의 일종으로, Key-Value 쌍으로 구성되어 있는 작은 기록 정보 파일입니다. 쿠키 이름, 쿠키 값, 만료 시간, 전송할 도메인 명, 전송할 경로, 보안연결여부, HttpOnly 여부로 구성되어 있습니다.

쿠키는 서버에서 생성되어 HTTP Response Header를 통해 클라이언트로 전송됩니다. 이후 클라이언트가 요청을 보낼 때 HTTP Request Header에 쿠키를 포함시켜 서버에 전송하고, 서버는 해당 쿠키의 값을 참조하여 클라이언트의 상태를 파악합니다.

Cookie의 장점

• 구현이 간단하고, 클라이언트 측에 데이터를 저장하기에 서버의 부하가 적습니다
• 쿠키는 만료일이 지나기 전까지 계속 유효하며, 클라이언트 측에서도 쉽게 삭제할 수 있습니다
• 다른 도메인에서 사용할 수 있는 경우 쿠키를 공유할 수 있습니다.

Cookie의 단점

• 사용자의 브라우저에 의존하므로 사용자가 쿠키를 거부할 수 있습니다
• 쿠키는 작은 용량으로 제한되어 있기 때문에, 많은 양의 데이터를 저장할 수 없습니다

 

3. JWT 방식

JWT는 Json Web Token의 약자로, 인증에 필요한 정보들을 암호화시킨 토큰을 말합니다.

JWT 토큰에는 사용자의 인증 정보뿐만 아니라, 필요한 추가 정보도 함께 포함될 수 있습니다. 클라이언트가 서버에 요청을 보낼 때, 해당 JWT 토큰을 함께 전송하여 서버가 해당 사용자의 인증 정보를 확인하고 인가를 수행하게 됩니다.

JWT의 구성요소

JWT는 헤더(header), 페이로드(payload), 서명(signature)으로 나누어집니다.

• 헤더 : 토큰 타입, 암호화 알고리즘 명시
• 페이로드 : 전달하려는 정보
• 서명 : 토큰 변조 여부 확인

JWT의 장점

• 클라이언트에서 인증 정보를 관리하므로 서버의 부하가 적습니다
• 클라이언트에서 인증 정보를 관리하므로 서버의 확장성이 높습니다

JWT의 단점

• 클라이언트에서 인증 정보를 관리하기 때문에 클라이언트에서 토큰을 조작하거나 탈취하는 등 보안성이 취약합니다
• 서버와 클라이언트 모두에서 인증 정보를 관리하기 때문에 구현이 어려울 수 있습니다

 

OAuth 2.0 방식

OAuth 2.0 방식은 Google이나 Facebook 같은 제 3자 애플리케이션이 사용자를 대신해 HTTP 서비스를 이용할 수 있는 권한을 부여하는 개방형 표준 프로토콜입니다. 이를 통해 사용자의 로그인 정보를 신뢰할 수 있는 서비스의 계정을 활용하여 안전하게 로그인하거나 데이터를 공유할 수 있습니다.

OAuth의 대표적인 권한 부여 방식

1. Authorization Code Grant(권한 부여 승인 코드 방식)
   : 가장 일반적인 OAuth 2.0 인증 방식으로, 이 방식은 리다이렉션을 통해 사용자가 신뢰할 수 있는 인증 서버에서 인증을 받게 됩니다.
   권한 부여 승인 코드 방식은 사용자의 자격증명이 클라이언트 애플리케이션에 노출되지 않도록 한다.
   주요 단계
   1. 클라이언트 애플리케이션은 사용자를 인증 서버로 리다이렉션하여 인증을 요청합니다.
   2. 인증 서버는 사용자에게 로그인 페이지를 제공하여 사용자의 자격증명을 받습니다.
   3. 인증이 성공하면, 인증 서버는 사용자에게 클라이언트 애플리케이션이 요청하는 접근 범위에 대해 인가를 받습니다.
   4. 사용자가 인가를 승인하면, 인증 서버는 사용자를 클라이언트 애플리케이션의 리다이렉트 URI로 다시 리다이렉트합니다.
   5. 클라이언트 애플리케이션은 인증 코드와 자신의 클라이언트 ID, 비밀 키, 그리고 리다이렉트 URI를 사용하여 인증 서버에게 엑세스 토큰을 요청합니다.
   6. 인증 서버는 클라이언트 애플리케이션의 요청을 검증하고, 검증이 완료되면 엑세스 토큰을 발급합니다.
   
   
2. Implicit Grant (암묵적 승인 방식)주요 단계
   : 웹 브라우저 등에서 직접 실행되는 애플리케이션에서 주로 사용되는 방식으로, Authorization Code 흐름보다 간단하지만 액세스 토큰이 클라이언트에 직접 노출되므로 보안상 문제가 있을 수 있습니다
   주요 단계
   1. 클라이언트 애플리케이션은 사용자를 인증 서버로 리다이렉션하여 인증을 요청합니다.
   2. 인증 서버는 사용자에게 로그인 페이지를 제공하여 사용자의 자격증명을 받습니다.
   3. 인증이 성공하면, 인증 서버는 사용자에게 클라이언트 애플리케이션이 요청하는 접근 범위에 대해 인가를 받습니다.
   4. 사용자가 인가를 승인하면, 인증 서버는 사용자를 클라이언트 애플리케이션의 리다이렉트 URI로 다시 리다이렉트합니다. 이때 엑세스 토큰이 URI의 fragment(#으로 시작하는 부분)에 포함되어 전달됩니다

이외에도 Resource Owner Password Credentials Grant (자원 소유자 자격증명 승인 방식), Client Credentials Grant (클라이언트 자격증명 승인 방식) 등이 더 사용됩니다.

OAuth의 장점

• 사용자의 인증 정보를 직접 공유하지 않으며, 제 3자 애플리케이션에 필요한 최소한의 권한만 부여할 수 있습니다.
• OAuth 2.0은 다양한 유형의 애플리케이션(웹, 모바일, 서버)을 지원하며, 다양한 시나리오에 맞게 설정할 수 있습니다

OAuth의 단점

• OAuth 2.0은 기술적으로 복잡한 프로토콜로, 구현이 어렵고 오류가 발생하기 쉽습니다
• OAuth 2.0은 Google, Facebook 같은 제 3자 애플리케이션에 의존하여 데이터를 처리하는 방식이고, 이러한 대형 서비스들이 사용자의 데이터에 대한 통제력을 지니고 있습니다

참고 자료

• https://puleugo.tistory.com/138
• https://velog.io/@hahan/JWT란-무엇인가
• https://develop-const.tistory.com/14
• https://choimungu.tistory.com/206
• https://velog.io/@jy3026/OAuth2.0란-무엇인가