[Web] 로그인 방식의 종류

zeew00·2024년 9월 4일

2024 하계 방학 Front-End Mentoring

목록 보기

32/32

로그인 API가 보다 복잡한 이유는 우선 HTTP의 특성과 관련이 있습니다.
HTTP는 무상태성이라는 특성을 지니고 있는데 클라이언트에 대한 이전 상태 정보
및 현재 통신 상태가 남아있지 않아 이를 해결하고자 로그인 방식이 별도로 존재합니다.

HTTP의 특성인 무상태성(Stateless)은 무엇일까?

이는 말 그대로 상태를 유지하지 않는다.라는 뜻이며 상태를 유지 하지 않기 때문에
클라이언트와 연결된 서버에 장애가 발생했더라도 클라이언트가 요청 정보를 기억하고 있어서 다른 서버를 연결하더라도 문제가 발생하지 않습니다.

위와 같은 이유로 무상태성(Stateless)은 수평 확장에 유리합니다.
추가로 수평 확장이란 시스템의 처리 능력 향상을 위해 서버의 수를 늘리는 방식을
말하며 이를 통해 어플리케이션이 더 많은 트래픽을 처리할 수있도록 확장합니다.

무상태성과 수평 확장은 함께 사용되며 분산 시스템의 성능과 확장성을
극대화합니다. 아래에선 위와 같은 방식의 예를 들어 보겠습니다.

Stateless는 고객이 주문 정보를 기억하고 있기 때문에 중간에
다른 점원으로 바뀌어도 주문을 정상적으로 할 수 있습니다.

만약 고객의 요청이 증가하더라도 여러 점원을 투입할 수 있기 때문에
위에서 설명드렸던 확장성에 용이합니다.

Cookie

클라이언트가 어떠한 웹사이트를 방문할 경우 그 사이트가 사용하고 있는
서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일을 뜻합니다.

무상태 환경에서 기억하고자 하는 데이터를 쿠키에 담고 다음 번 요청 시
쿠키를 요청에 함꼐 담아 보냄으로써 무상태를 극복합니다.

아래 사진은 쿠키의 인증 과정을 나타내는 예제 사진입니다.
1. 사용자의 로그인 요청
2. 로그인 성공 시 서버는 새로운 쿠키를 생성
3. 생성된 쿠키에 회원 정보를 담아 응답
4. 사용자는 브라우저 저장소에 쿠키를 저장
5. 다음 번 요청 시 쿠키를 요청에 함께 전달
6. 서버는 쿠키를 보고 유저를 확인 후 응답

쿠키의 단점

보안에 취약하여 쿠키가 전달될 때 개인정보가 외부에 노출될 수 있습니다.

적은 용량으로 인해 많은 정보를 담을 수는 없습니다.

웹 브라우저마다 쿠키에 대한 지원 형태가 상이해 공유가 불가능합니다.

쿠키의 사이즈가 커질수록 네트워크의 부하가 심해집니다.

Session

쿠키의 단점을 보완한 것이 바로 세션이며 개인정보를 HTTP로 주고 받는 것은
보안상의 위험이 있기 때문에 세션은 비밀번호와 같은 클라이언트의 인증 정보를
쿠키가 아닌 서버측에 저장하고 관리합니다.

아래는 세션의 인증 과정에 대한 사진 및 설명입니다.

사용자의 로그인 요청

로그인 성공 시 서버에서 세션ID를 생성 및 저장

쿠키에 생성한 세션ID 정보를 담아 응답

사용자는 브라우저 저장소에 쿠키를 저장해두고 다음 요청시에 쿠키를 함께 전달

서버는 쿠키를 확인하고 세션ID에 대응되는 유저가 누구인지 확인 후 응답

세션의 장점

쿠키를 포함한 요청이 외부에 노출되더라도 유의미한 개인정보가 없기에 안전합니다.

세션의 단점

해커가 쿠키를 중간에 탈취하여 마치 해당 유저인척 위장할 수 있습니다.

서버의 세션 저장소 구축으로 인한 관리의 부담이 있습니다

JWT(JSON Web Token)

JWT이란 인증에 필요한 정보들을 암호화 시킨 토큰이며 쿠키를 대신합니다.

JWT 토큰의 구조는 .을 구분자로 사용하여 3 가지로 나눠진 문자열의 조합이며
Header, Payload, Signature 아래와 같이 이렇게 세 종류로 나누어지고
JWT는 서버가 클라이언트로부터 받은 토큰의 진위를 검증하는 데에 사용됩니다.

'Header'

헤더의 역할은 토큰의 타입과 사용된 암호화 알고리즘을 지정하고
일반적으로 두 가지 필드(alg, typ)를 포함합니다.

alg : 사용된 암호화 알고리즘 (HS256, RS256)

typ : 토큰의 타입 (JWT)

다음은 JSON으로 작성된 헤더의 예시입니다.
{
	"alg": "HS256", 
  	"typ": "JWT"
}
'Payload'

페이로드의 역할은 토큰에 담길 실제 데이터인 claim을 포함하고
클레임은 토큰의 정보나 속성을 담고 있으며 아래의 유형으로 나뉩니다.

등록된 클레임 (Registered Claims) : JWT의 표준화된 클레임
(iss : 발행자, exp : 만료일, sub : 주제 등)

공식 클레임 (Public Claims) : 사용자 정의 클레임으로
다른 시스템에서 공통적으로 사용할 수 있는 클레임입니다.

비공식 클레임 (Private Claims) :
특정 어플리케이션 간에 공유되는 사용자 정의 클레임

다음은 JSON으로 작성된 페이로드의 예시입니다.
  {
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
'Signature'

시그니처의 역할은 토큰의 무결성을 검증하고 위조를 방지하고
헤더와 페이로드를 결합하여 비밀 키를 사용하여 서명합니다.

헤더와 페이로드를 각각 Base64Url로 인코딩합니다.

인코딩된 두 문자열을 옥탯(.)으로 구분하여 결합합니다.

결합된 이 문자열에 대해 지정된 알고리즘과
비밀 키를 사용하여 해시를 생성합니다.

다음은 HS256 알고리즘을 사용한 시그니처의 예시입니다.
  HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)
JWT 인증 과정

클라이언트 로그인 요청

로그인 성공 시 유저 정보 및 유효기간 등을 Payload에 담고
비밀키를 사용해 Access Token(JWT)을 발급

서버는 생성한 JWT 토큰을 클라언트에게 전달

클라이언트는 전달 받은 토큰을 저장해두고 요청할 때마다
토큰을 요청 헤더 Authorization에 포함시켜 함께 전달

서버는 받은 JWT의 헤더, 페이로드 비밀 키를 더해
함호화 + 암호화 값이 JWT의 Signature와 일치하는지 판단 후
유효 기간 등을 확인하여 유효한 토큰인지 확인

유효한 토큰이라면 요청에 응답

Token Header(암호화 알고리즘) + Payload(유저정보, 유효기간) + 서버 비밀키 = Signature

JWT 단점

쿠키와 세션에 비해 데이터의 길이가 길어 네트워크 부하 가중

페이로드 자체느 암호화가 되지 않기 때문에 중요한 정보를 담을 수 없음

현재 로그인 중인지 여부 판별 불가

토큰을 탈취 당할 시 대처를 하기가 어려움

JWT 단점 보완

아래의 사진과 같이 Refresh Token을 추가로 두어 단점을 보완할 수 있습니다.

클라이언트의 로그인 요청

로그인 성공 시 Access Token(긴 유효 기간)과
Refresh Token(짧은 유효 기간)을 발급 후 DB에 저장

서버는 생성한 Refresh Token을 클라이언트에 전달

클라이언트는 토큰을 저장해두고 요청할 때마다
Refresh Token을 요청 헤더에 포함시켜 함께 전달

서버는 유효한 토큰인지 확인하여 응답하고 이 때 유효 기간이 지난
Refresh Token은 DB에서 Access Token과 비교 후 재발급 응답을 우선 수행

유효한 토큰이라면 요청에 응답

OAuth(Open Authorization)

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상에서 자신들의 정보에 대해 웹사이트나 어플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는 접근 위임을 위한 개방형 표준입니다.
무슨 말인지 이해가 어렵다면 간단히 SNS의 로그인 방식을 떠올리면 좋습니다!!

OAuth 참여자

Resource Server : 클라이언트가 제어하고자 하는 자원을 보유한 서버
(예시로 Google, Naver, Kakko 등이 있습니다.)

Resource Owner : 자원의 소유자(클라이언트 서비스를 통해 로그인하는 실제유저)

Client : 자원 서버에 접속해 정보를 가져오고자 하는 클라이언트(내 서비스)

OAuth 인증 과정

1. Client 등록 및 설정

클라이언트는 자원 서버를 이용하기 위해 자신의 서비스를 등록

등록을 마치면 클라이언트는 자원 서버로부터
클라이언트 ID, Secret 등의 정보를 제공 받습니다.

자원 서버는 클라이언트 ID, Secret 등의 정보로 클라이언트를 구분

2. Resuorce Server의 시용지 인증과 권한 동의 요구

자원 소유자가 소셜 로그인 버튼을 누르면 클라이언트를 통해
자원 서버 로그인 페이지로 리다이렉션

자원 서버에서는 요청한 클라이언트의
ID, Secret 값 등을 확인하고 로그인을 승인하여
자원 소유자에게 클라이언트로 정보 위임 권한을 넘겨줄 것인지 질의

자원 소유자가 권한 동의를 마치면 자원 서버는 클라이언트가 등록한
리다이렉션 URL로 Authorization code를 담아서 요청

3. Access Token 발급

Access Token : 사용자의 정보를 볼 수 있는 권한을 부여해줍니다.

클라이언트는 ID와 비밀키 및 발급 받은
Authorization Code 값을 자원 서버에 전달

자원 서버는 정보를 검사한 다음 유효한 요청일 시 Access Token을 발급

4. Access Token 활용

클라이언트는 해당 토큰을 통해 자원 서버의
사용자 자원을 사용하기 위한 API 호출 시
해당 토큰을 헤더에 담아서 전송

자원 서버는 Acces Token을 검증하고 사용자 정보를 회신

클라이언트는 받아온 사용자 정보를 갖고 회원가입 및 로그인 기능을 수행