[WEB] 프론트, 서버 인증 / 권한 부여 방법 (OAuth, session, JWT) / acessToken, refreshToken)

 

 

---

인증이란?

프론트 관점 : 로그인, 회원가입과 같은 도입부

서버 관점 : 모든 API 요청에 대한 사용자 확인 작업

인증이 제대로 이루어지지 않는 다면?

정보가 유출되는 상황이 생김

정확한 인증을 위해서는..

자신이 누구인지 알수있는 정보를 프론트에 입력해서, 서버는 그 정보로 요청에 맞게 데이터를 뿌려주어야 한다.

 

인증 방식 3가지

1. 계정정보를 요청 헤더에 넣는 방식
2. 토큰 기반 인증 방식
3. Access Token & Refresh Token 방식

 

1. 계정정보를 요청 헤더에 넣는 방식 (HTTP)

• 웹, 모바일 서비스에서 가장 많이 사용하는 통신 방식
• 서버에 요청을 보낸다 = 웹에서 HTTP 메세지를 전송한다.
• HTTP는 기본적으로 헤더, 바디로 구성되며, 헤더에 인증 방식을 직접 넣어 요청을 보낸다.
  • 비연결성
  • 단방향 통신

장점 : 테스트가 편하다

단점 : 보안에 매추 취약하다

 

2. 쿠키, 세션 방식

• 사용자 로그인 인증 및 인가를 위해 사용한다.
• 계정정보를 읽고 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장 후 세션 ID를 발행
• 사용자는 세션ID를 쿠키에 저장한후 인증 요청시마다 쿠키를 헤더에 실어서 보내는 방식

장점 : 인증 방식보다 보안성이 높다. , 회원정보를 확인하지 않고 ID로 확인할 수 있다.

단점 : 세션 저장소가 필요하고 서버 부하가 될 수 있다. 쿠키 정보를 훔칠수 있다.

(쿠키 탈취 관련해서는 유효시간을 통해 해결함)

 

 

3. 토큰 기반 인증 방식

• 엑세스 토큰을 jwt 형식으로 변환하여 헤더에 전달한다.
• 쿠키의 용량제한으로 인해 http 헤더에 Authorition을 사용하여 토큰 인증 및 인가 방식이 사용되게 되었다.

장점 : 고유 id로 암호화 되어 탈취해도 알아내기 어렵다., 세션ID외 사용자 정보를 전달 받을 수 있다., 서버리스 개발이 가능하다 → 추가 저장소가 필요없다.

단점 : 이미 발급한 jwt를 조작할 수 없다., Payload 정보가 제한적이다.

(엑세스 토큰 유효시간을 줄이고, 리플레시 토큰을 발급하여 갱신하도록 한다.)

Access Token

• 3자 탈취 시 보안에 취약하다.
• 유효기간이 길 수록 토큰 탈취시 보안에 취약해진다.
• 유효기간을 짧게 하면서 JWT인증 방식을 사용하는 방법은 Refresh Token을 같이 사용하는 것

Access Token 특징

- 액세스 토큰은 클라이언트가 리소스에 접근할 때 리소스 서버에 제공된다.

- 클라이언트는 리소스에 대한 권한을 인증하고 접근한다.

- 액세스 토큰은 일반적으로 OAuth 인증 서버로부터 발급되지만, 이를 JWT 형식으로도 사용할 수 있다. ( JWT는 액세스 토큰을 포함하는 방식)

- JWT과 같이 사용 시 액세스 토큰의 페이로드 부분을 JWT 형식으로 구성하여 사용한다.

- JWT는 액세스 토큰을 토큰의 내용을 암호화하고 서명하는 데 사용되고, 이를 통해 토큰의 무결성과 보안을 강화한다.

 

Refresh Token

• Access Token과 똑같은 형태의 JWT
• Access Token이 유효기간이 종됐을 때 새로 발급해주는 열쇠
• Refresh Token의 유효기간이 만료됐다면, 사용자는 새로 로그인해야 함.

Access Token 만료 시

• 사용자는 Refresh Token과 Access Token을 함께 서버에 전달
• 서버는 받은 Access Token이 조작되지 않았는지 확인
• 서버는 rfresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교
• Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 헤더에 실어 줌

장점 : Access Token 보안에 안전하다.

단점 : 구현이 복잡하다. HTTP 요청 횟수가 많아질 수 있다.

 

 

추천하는 인증 구현 방법?

• accessToken은 JSON payload로 받고 accessToken은 웹 어플리케이션 내 로컬 변수에 저장(store) 수동으로 API 요청시 Authorization 헤더에 넣기
• refreshToken은 secure httpOnly 쿠키 저장하여 서버에 accessToken 요청 시 자동 헤더에 전달
• refreshToken을 set-cookie로 저장하여 http 요청시 자동으로 전달되지만, 다른 페이지혹은 도메인에서는 세션id가 유효하지 않게 처리하여 조작할 수 없게 한다.

 

 

 

권한 부여 방식 3가지

1. Session
2. JWT (JSON Web Token)
3. OAuth (Open Authorization)

 

1. Session

• 사용자의 로그인 정보 등을 저장하는 저장소
• 강제 로그아웃, 다른 디바이스에서 로그인한 계정 확인, 해당 계정으로 로그인한 사용자 수 확인 및 제한 등의 작업을 수행 하는 데 사용
• 세션은 모든 정보를 가지고 있어서 로그인 정보를 가지고 여러 기능을 만들 수 있다.
• 일반적으로 세션은 DB에서 관리되며, 보통 Redis와 같은 메모리 데이터베이스를 사용

 

2. JWT (JSON Web Token)

• 데이터를 안전하게 전달하기 위한 토큰 기반의 인증 방식
• 2015년 웹표준화 되었다.
• 토큰정보에 공유하고자하는 개인정보( 사용자 ID, 권한, 만료 시간 )를 넣어 암호화 시키는 방식으로 쿠키보다 많은 정보를 교환할 수 있다.
• JSON 형식을 사용하여 정보를 교환하며, Base64로 인코딩되어 페이로드로 전송
• 로그인 권한, 사용자 이름, 닉네임 등의 정보를 토큰에 담아 클라이언트단에서 로그인을 검증하고 인증하는 데 사용
• 예를 들어 QR코드를 사용한 로그인과 같은 기능을 구현가능

 

인증서버와 같이 사용하는 JWT

• jwt 사용 시 서드파티 로그인을 하게 될때, 2번 로그인을 해야하는 불편한과 보안 취약점이 존재하여 인증서버를 사용하게 되었다.
• JWT는 stateless하며, 토큰 자체에 사용자 정보를 포함하고 있어 별도의 세션 저장소가 필요하지 않다. 즉 DB 없이도 로그인을 인증할 수 있습니다.
• 특히 refreshToken을 사용할 경우에는 DB에 저장할 필요가 있지만, 기본적으로 세션이나 DB 없이도 로그인을 인증할 수 있는 기능을 제공
• 인증서버에서 oauth를 통해 인증을 받게되면 토큰을 발급해주는데 이 토큰을 사용하여 사용자가 인가를 받아 리소스에 엑세스 할 수 있다.

 

3. OAuth (Open Authorization)

• 접근 권한을 증명하는 토큰을 발급해주는 프로토콜
• OAuth 2.0은 표준 인증 프로토콜이며, 사용자가 자신의 리소스를 안전하게 제3자에게 제공할 수 있는 개방형 인증 및 권한 부여를 위한 프레임워크이다.
• 역할은 클라이언트, 리소스 소유자, 리소스 서버, 인증 서버가 있다.

인증서버 기능

• 주로 서드파티 로그인에 사용되며, 소셜 로그인을 포함한다.(카카오톡, 네이버, 구글 등)
  
• 클라이언트 애플리케이션이 리소스 소유자의 자원에 접근할 수 있는 권한을 얻는 데 사용한다.
• OAuth 프로토콜을 사용하여 사용자 인증 및 권한 부여를 처리하고, 이를 위한 액세스 토큰으로 JWT를 사용하는 경우가 많습니다.
• OAuth는 사용자가 자신의 비밀번호를 직접 공유하지 않고도 다른 웹사이트나 애플리케이션에서 사용자의 정보에 접근 권한을 부여해준다.

 

QnA

Q1. OAuth를 사용하지않으면 acessToken을 얻지 못하는 건가?

- Oauth를 사용하지 않은 경우 엑세스 토큰 발급은 어떻게 받고, 리소스 접근에 인가를 어떻게 허용했을까?

 

A1. 서버에서 따로 인증 프로세스나 프레임워크를 사용하여 엑세스 토큰을 만들 수도 있다.

- 로그인 성공 시 응답값으로 엑세스 토큰을 전달하고, 그 다음 인가가 필요한 요청은 엑세스 토큰을 전달하여 확인하는 방식이다.

 

 

Q2. 세션 ID를 DB 리소스에 저장하는 것과 refreshToken을 DB 리소스에 저장하는 것 차이?

- 로그인 후 서버에서 세션 정보를 DB에 저장하고 그 중에 세션 ID를 클라이언트에게 전달하는것과 로그인 후 서버는 refreshToken DB에 저장하고 클라이언트에게 acessToken와 refreshToken을 전달하는 것 중 보안 상, 성능 상으로 더 좋은 방식은 무엇일까?

 

A2. 사용자 수가 적거나 DB 리소스가 작은 경우 JWT를 사용하여 개발 해도 되지만, 사이트 규모가 커질 수록 session을 사용하는 것이 좋다.

DB 리소스 사용량, 보안 보다는 어떤 기능을 구현할 것인지, 사용자수나 서버 환경이 어떻게 되는지에 따라 사용하는 기준이 달라진다.

 

 

추천하는 권한 부여 방식?

사용자 수가 적거나 DB 리소스가 작은 경우 JWT를 사용하여 개발 해도 되지만,

사이트 규모가 커질 수록 session을 사용하는 것이 좋다.

DB 리소스 사용량, 보안 보다는 어떤 기능을 구현할 것인지, 사용자수나 서버 환경이 어떻게 되는지에 따라 사용하는 기준이 달라진다.

 

 

서드 파티 로그인 (Third Party Login)

• 사용하는 서비스에서 타 서비스(앱 또는 웹 사이트)에 자격증명을 인증하는 방식
  • 타 서비스 계정을 보유 및 등록 작업 필요
  • 인가코드를 통해 사용자를 인증하고 리소스를 요청시 필요한 토큰을 전달해준다.
• 개발자는 보안 및 인증과 부담 감소하여 로그인을 구현할 수 있다.
• 서드 파티 로그인은 간편 로그인의 한 형태로 사용된다.

 

간편 로그인 (Convenient Login)

• 기존의 회원가입을 위한 인증 프로세스나 로그인 과정을 대폭 줄여 간편하게 서비스 이용을 할 수 있게 하는 방식
  • 별도의 계정 생성 없이 편리하게 로그인을 한다는 의미
• 클라이언트와 특정 서버를 연동시켜 간편로그인 방식을 구현할 수 있다.

예)

소셜 로그인

• 사용자가 자신의 웹서비스 계정(예: 구글, 페이스북, 트위터)을 사용하여 타 서비스에 회원가입/로그인하는 방식
• 사용자가 이미 소셜 미디어 계정을 보유하고 있기 때문에 새로운 계정을 생성할 필요 없다.

기기 인증

• 기기 인증은 사용자가 휴대폰 또는 이메일을 통해 받은 일회용 코드를 입력하여 로그인하는 방식
• 휴대폰 또는 이메일을 통해 인증할 수 있어 사용자가 별도의 비밀번호를 기억할 필요 없다.

자동 로그인

• 사용자가 한 번 로그인한 후에는 애플리케이션을 재 실행할 때 정보를 입력하지 않고도 자동으로 로그인되는 방식
• 사용자가 다시 로그인할 필요 없다.

 

마무리

-  JWT와 OAuth는 각각 다른 개념이지만, 웹 인증과 인가를 위해 흔히 함께 사용된다. 
- jwt는 인증 토큰이고
- OAuth는 토큰을 발급해주는 프로토콜이다.
- 인증 서버가 따로 없는 경우 서버에서 jwt만을 사용하여 인증 및 인가를 처리하고,
인증서버를 사용하는 경우 OAuth 를 사용하여 엑세트 토큰으로 인증 및 인가를 처리한다. 이 때 엑세스 토큰의 보안 강화를 위해 jwt 형식으로 엑세스 토큰을 만들어서 전달하는 경우가 있다.