[Spring Security] 소셜 로그인 구현기 (로그인 개념, JWT) - 1

🚀 로그인에 대해

⭐ 로그인이란?

"로그인"

웹 개발 입문하고 프로젝트를 해 봤으면

한 번쯤은 로그인 구현에 대해 고민해 봤을 것이라고 생각한다.

 

로그인이란 무엇일까?

접근 권한을 얻기 위해 시스템에 자기 자신을 증명하는 것을 말한다.

여기서 증명과 접근 권한이라는 말이 나온다.

개발에서 좀 더 자주 사용하는 단어로 치환해서 말하자면

증명은 인증(Authentication),

접근 권한은 인가(Authorization)라고 말할 수 있다.

 

예를 들어,

• 게임 안에 있는 내 캐릭터에 접속하기 위해선
  게임 서버로부터 자신이 캐릭터 주인임을 인증(증명)하고 인가(접근 권한)를 받아야 한다.
• 쇼핑몰에 접속해 원하는 물건을 주문하기 위해선
  쇼핑몰 서버로부터 자신이 쇼핑몰에 가입되어 있는 특정 인물임을 인증(증명)하고
  주문할 수 있는 자격인 인가(권한)를 받아야 한다.

위 과정을 위해 로그인이라는 것이 존재한다.

인증 과정을 거쳐 내가 해당 서비스의 회원임을 증명하고 인가를 받는 것.

 

요즘은 마우스 몇 번 클릭이면 로그인이 되는 세상이다.

유저에게 간단하고 쉬운 로그인을 제공하기 위해

화면 뒤편에선 많은 구현 과정들이 이루어지고 있다.

 

개발자의 관점

특히, 백엔드의 관점으로 로그인 구현 과정을 기록하고 싶다.

 

로그인 구현은 정말 다양한 방식으로 할 수 있다.

그중 현재 진행하고 있는 프로젝트에 적용한 방식으로 기록할 예정인데

• Spring Boot 3
• Spring Security 6
• JWT
• OAuth 2.0

이러한 기술스택을 적용한 경험을 기록한다.

⭐ Spring Security를 사용하는 이유

로그인 구현 난이도를 상당히 올려주는

Spring Security를 굳이 사용하는 이유는

아래 링크를 참고.

👉 [Spring Security] 보안과 Spring Security

???: 시큐리티 구현 난이도나 시간이 부담이 되어서 도입하기 싫어요.

그렇다면 모든 요청에 대한 인증, 인가 로직을 직접 구현하셔야 한다.

물론 Spring Security도 본인 서비스에 맞게 커스텀이 들어가야 한다.

하지만 직접 필터나 인터셉터를 구현하는 것보단

기본적인 보안 인증 필터 및 로직 제공, 공식 문서 및 레퍼런스가 많은 Spring Security 사용이 좀 더 수월할 수 있다.

역시 전자던 후자던 이것도 하기 나름.

 

그러므로

로그인을 디테일하게 구현하고 싶지 않고 간단하게 구성하고 싶으면

얼마든지 시간, 노력을 줄여서 구현할 수 있다.

하지만 그만큼 사용자의 로그인은 신뢰도가 떨어지는 반비례를 가진다.

따라서 Spring Security 도입을 무조건 할 필요는 없다.

개발에서 무조건은 없기 때문에

본인의 프로젝트 크기, 마감 시간, 상황 등에 따라 유연한 판단이 필요하다.

 

이전에는 잘 모르고 무작정 썼었기 때문에

이번 프로젝트에 다시 적용하면서 제대로 알아보기로 했다.

평소에 보안을 중요하게 생각하기도 하고

좀 더 알고 써봤으면 좋겠다는 마음에

우선 Spring Security 6 유료 강의를 들었고

공식 문서 및 다양한 레퍼런스를 참고했다.

 

그래도 여전히 너무 어렵다 ㅠ

---

🚀 JWT(Json Web Token)

⭐ JWT란?

인증에 필요한 정보들을 암호화시킨 JSON 토큰이다.

JWT는 JSON 데이터를 Base64 URL-safe Encode를 통해 인코딩하여 직렬화한 것이고,

토큰 내부에는 개인키를 통한 전자서명이 들어있다.

※ Base64 URL-safe Encode란, 일반적인 Base64 Encode를 URL에서 오류 없이 사용하도록
'+'와 '/'를 각각 '-', '_'으로 표현한 것이다.

 

JWT는 세 가지 요소로 구성되어 있다.

• Header
• Payload
• Signature

마침표로 각 요소를 구분한다.

출처: fakerdeft

 

프로젝트에서 사용되고 있는 토큰을 뜯어보며 각 요소를 설명한다.

 

1. Header(알고리즘 & 토큰 타입)

출처: fakerdeft

Header에는 전자서명 시 사용된 알고리즘과 토큰의 타입을 저장한다.

현재 프로젝트에 적용한 JWT에서는 HS512 알고리즘을 사용하고 있다.

 

2. Payload(데이터)

출처: fakerdeft

Payload에는 Claim이라는 토큰에서 사용할 정보들이 담겨있다.

위의 PAYLOAD에서 key-value 형식으로 이루어진 하나의 쌍들이 모두 Claim이다.

인증 시에 토큰에서 실제로 사용될 정보를 의미한다.

여러 Claim들을 JWT 토큰 생성 시에 개발자가 어떤 Claim을 넣을지 정한 후 마음대로 넣을 수 있다.

 

JWT의 표준 스펙에는 7개의 Claim이 정의되어 있다.

모두 필수로 사용하는 것은 아니다.

1. iss(Issuer) : 토큰 발급자
2. sub(Subjec) : 토큰 제목 - 토큰에서 사용자에 대한 식별값이 된다.
3. aud(Audience) : 토큰 대상자
4. exp(Expiration Time) : 토큰 만료 시간
5. nbf(Not Before) : 토큰 활성 날짜 (이 날짜 이전의 토큰은 활성화 되지 않음을 보장)
6. iat(Issued At) : 토큰 발급 시간
7. jti(JWT Id) : JWT 토큰 식별자 (issuer가 여러 명일 때 구분하기 위한 값)

이렇게 표준 스펙에 7개의 Claim이 정의되어 있고,

필요하다면 개발자가 추가로 작성해도 문제가 없다.

제 프로젝트에서도 토큰에서 사용자의 고유 번호와 권한을 추출하기 위해,

위의 JWT Payload에서 3번째, 4번째 Claim으로 사용자 정의 Claim인 'memberId', 'role'을 별도로 추가했다.

 

이때, 주의해야 할 점은 Payload에는 암호화가 되어 있지 않기 때문에, 민감한 정보를 담지 않아야 한다.

누구나 JWT Decoding을 통해 Payload의 정보를 볼 수 있기 때문에

단순하게 "식별을 위한" 정보만을 담아두어야 한다.

 

3. Signature(서명)

출처: fakerdeft

Signature는 암호화되어 있기 때문에,

외부에서 복호화를 진행해도

실제 서명이 나오지 않고, 암호화의 구조만 나타나게 된다.

 

암호화 구조를 살펴보면, 앞서 JWT 정의에 대해서 말할 때 언급되었던

Base64 URL-safe Encode를 사용한 Header와 Payload를 암호화한 것을 볼 수 있다.

그다음은 your-256-bit-secret로 

서버가 가지고 있는 고유 개인키를 암호화했기 때문에

외부에서 Signature를 복호화 할 수 없는 것이다.

 

JWT 기반 인증 방식은

토큰 자체에 사용자의 정보들이 포함되어 있다는 점(Self-contained)이 특징이다.

클라이언트의 상태를 알아야 했던 Stateful 방식에서 JWT 방식으로 바꾸게 되면

서버가 클라이언트의 상태를 저장하지 않아도 되기 때문에 Stateless하게 설계가 가능하다.

 

보통 JWT 기반 인증은 다음과 같은 순서로 진행된다.

1. 사용자가 서버에 로그인 요청

2. 서버에서 서명된 JWT 토큰을 생성하여 클라이언트에 응답으로 반환

3. 클라이언트는 응답으로 반환된 토큰을 사용하여 요청 시 마다 HTTP Header에 토큰을 담아 요청

4. 서버에서는 요청 Header에 있는 토큰이 유효한지 검증 후 유효하다면 요청에 맞는 응답 반환

 

⭐ Access Token & Refresh Token

Access Token은 보통 인증 시 사용되는 JWT를 말한다.

 

하지만

만약 해커가 Access Token을 탈취한다면 어떻게 될까?

해커는 탈취한 Access Token을 사용하여 사이트 내 인가가 필요한 접근이 모두 가능해질 것이다.

 

이를 해결하기 위해 Access Token의 유효 기간을 짧게 하면 해결할 수 있다.

토큰이 털리더라도 그 Access Token은 짧은 시간 동안 밖에 못 쓰기 때문에 대응이 되는 것이다.

 

공교롭게도

Access Token의 유효 기간을 짧게 설정하게 되면 유저 입장에서 매우 귀찮고 번거로울 것이다.

짧은 주기마다 재로그인을 해서 Access Token을 발급받아야 하기 때문이다.

따라서 '해커 탈취 문제-사용자의 이용성'에 trade-off가 발생하게 되는 것이다.

 

이러한 trade-off를 해결해 주는 것이 바로 Refresh Token이다.

Refresh Token은 인증이 아닌, Access Token을 재발급 해주는 역할의 JWT다.

• Access Token은 인증 처리 역할
• Refresh Token은 Access Token 재발급 역할

마치 호텔에서 방 키(Access Token)를 잃어버려도
신분증(Refresh Token)으로 자신을 증명해
다시 방 키(Access Token)를 얻을 수 있는 것과 같다.

 

Refresh Token을 사용한다면

Access Token의 유효 기간을 짧게 가져갈 수 있다.

사용자 입장에선 Access Token의 유효 기간이 짧아도

Refresh Token을 같이 보내면 Access Token의 재발급이 이루어지므로

계속 재로그인을 할 필요가 없어지는 것이다.

 

Access Token이 만료되면 Refresh Token을 함께 보내어

다시 Access Token을 재발급 받는 방식으로 로그인을 구현했다.

자세한 건 이후 글에서 기록한다.

---

🚀 결론

Session이나 Cookie를 사용하지 않고

JWT를 사용하는 이유는 다양한데,

서버에서 메모리를 잡아먹는 부담을 줄이고 확장성을 높이는

Stateless 인증 설계가 가능하기 때문이다.

 

여러 서버를 사용할 경우 Session/Cookie 방식은 동기화가 필요한 반면

토큰 방식은 어떤 서버로 요청이 가더라도 토큰 검증만 하면 되기 때문에

확장성이 좋다고 하는 것이다.

 

이외에도

• JWT는 정보를 암호화할 수 있으며, 서명이 되어 있어서 정보의 위변조를 방지할 수 있다.
  또한, SSL/TLS와 함께 사용하면 중간자 공격을 방지할 수 있다.
  Cookie를 사용할 때는 CSRF(Cross Site Request Forgery)와 같은 공격에 취약할 수 있다.
• JWT는 모바일 앱, 웹 앱 등 다양한 클라이언트와 손쉽게 통합될 수 있다.
  또한, CORS(Cross-Origin Resource Sharing) 문제에 대해서도 유연하게 대응할 수 있다.
  Session/Cookie 방식은 동일 출처 정책(Same-Origin Policy)에 더 엄격하게 제한될 수 있다.
• JWT는 OAuth, OpenID Connect와 같은 다양한 인증 및 권한 부여 프레임워크와 잘 작동한다.
  이를 통해 소셜 로그인 등 다양한 인증 방식을 쉽게 구현할 수 있다.

같은 이유들이 있다.

다음 글에서

OAuth 개념과

구현한 방식을 기록한다.

---

🚀 로그인 구현 과정 인덱스

• [Spring Security] 보안과 Spring Security
• 👉 [Spring Security] 소셜 로그인 구현기 (로그인이란, JWT) - 1
• [Spring Security] 소셜 로그인 구현기 (OAuth, 로그인 구조) - 2