[웹 개발 기초] 인증 Authentication이란?

안녕하세요
오랜만에 블로그 글 업로드를 하는데요

오늘은 최근에 공부를 한 인증 부분에 대해서 자세히 설명해드리겠습니다.

---

Authentication(인증) 필요한 이유..?

인증은 프론트엔드 관점에서 사용자의 로그인, 회원가입과 같이 사용자의 도입 부분을 가리키곤 합니다.
반면 백엔드 관점에서 봤을 때는 모든 API 요청에 대해 사용자를 확인하는 작업입니다.

예를 들어서 사용자 A와 사용자 B가 앱을 사용한다고 가정했을 때, 두 사용자는 기본적으로 정보가 다르고 보유하고 있는 콘텐츠도 다릅니다. 따라서 서버 A, B가 요청을 보냈을 때 누구의 요청인지를 정확히 알아야 합니다. 만일 그렇지 못한다면, 자신의 정보가 타인에게 유출되는 최악의 상황이 발생하겠죠?

그렇기 때문에 앱이나 웹에서는 자신이 누구인지를 알만한 단서를 서버에 보내야 하며, 서버는 그 단서를 파악해 각 요청에 맞는 데이터를 뿌려주게 됩니다.

<HTTP 요청>

현재 모바일이나 웹 서비스에서 가장 많이 쓰이는 통신 방식은 HTTP 통신입니다.
HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜입니다. 따라서 각각의 HTTP 요청에는 주체가 누구인지에 대한 정보가 필수적입니다.
(인증이 필요 없다면 필요 없을 수도 있겠죠 😄)

서버에 요청을 보내는 작업은 HTTP 메시지를 보내는 것입니다. HTTP 메시지의 구조는 위에와 같습니다. 헤더와 바디 두 가지로 구성되며. 공백은 헤더와 바디를 구분 짓는 역할을 합니다. 여기서 헤더에는 기본적으로 요청에 대한 정보들이 들어갑니다

---

Basic Authetication(기본 인증)

<Basic 인증>

 HTTP Basic 인증 기법은 HTTP 표준에 정의된 가장 단순한 인증 기법입니다.

클라이언트는 HTTP 요구를 송신합니다.
사용자의 이름과 비밀번호를 제공하는 방법입니다.
Authorization 단어를 포함하는 헤더 Basic 공백과 BASE 64 문자열 뒤에 이어지는 단어 username:password

주의, BASE64는 쉽게 디코딩되므로 기본 인증 HTTPS/SSL 등의 다른 보안 메커니즘과 함께 사용해야 합니다.

※순서※

1. 서버가 사용자에게 인증 요구를 보낼 때 서버는 401 Unauthorized 응답과 함께 WWW-Authenticate 헤더를 기술해서 어디서 어떻게 인증할지 설명
2. 다음으로 클라이언트가 서버로 인증 인코딩 된 비밀번호와 그 외 인증 파라미터들을 Authorization 헤더에 담아서 요청
3. 성공적으로 완료되면 정상적인 상태 코드를 반환한다. 추가적인 인증 알고리즘에 대한 정보를 Authentication-info 헤더에 기술

---

Session Authentication(세션 인증)

먹는 쿠키 아니고요..?

쿠키는 HTTP 쿠키입니다.
HTTP 쿠키(HTTP cookie)란 하이퍼 텍스트의 기록서(HTTP)의 일종으로서 인터넷 사용자가 어떠한 웹사이트를 방문할 경우 사용자의 웹 브라우저를 통해 인터넷 사용자의 컴퓨터나 다른 기기에 설치되는 작은 기록 정보 파일을 일컫는다.

Session과 Cookie를 사용합니다.

세션 : 서버에서 가지고 있는 정보

쿠기 : 사용자에게 발급된 세션을 열기 위한 열쇠를 의미

쿠키만으로 인증을 사용한다는 말은 서버의 자원을 사용하지 않는다는 것이다. 즉, 클라이언트가 인증 정보를 책임지게 됩니다. 그렇게 되면 보안 상으로 HTTP 요청으로 탈취를 당하게 됩니다.
보안과는 상관없는 단순한 장바구니나 자동 로그인 설정 같은 경우에는 유용하게 쓰입니다.

단점
CSRF(Cross-Site Request Forgery)에 대한 위험성을 안고 있습니다. CSRF는 공격자가 유저로 하여금 유저 본인들이 의도하지 않은 요청을 서버에게 보내도록 패스워드를 바꾸거나 결제를 하도록 유도하는 것입니다. Spring에서는 Security 부분에서 설정을 할 수가 있습니다.

<Session 인증>

※순서※

1. 유저가 아이디(이메일)와 비밀번호 등 필요한 로그인 정보를 HTTP 요청을 통해서 서버에 제출합니다.
2. 서버에서는 계정 정보를 읽어 일반적으로 DB 담겨 있는 유저의 로그인 정보와 대조하고, 정보가 일치하다면 세션 저장소에 저장한 후, 이와 연결되는 Session ID로 응답합니다.
3. 사용자는 서버에서 해당 Session ID를 받아 쿠키(브라우저 Key, Value 쌍을 저장할 수 있는 공간)에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냅니다.
4. 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져옵니다.
5. 인증이 완료되고 서버는 사용자에게 맞는 데이터를 보내줍니다.

---

Token Authentication

토큰 기반 인증이란 사용자 자신의 아이덴티티를 확인하고 고유한 액세스 토큰을 받을 수 있는 프로토콜을 말합니다.
토큰 유효 기간 동안 웹페이지나 앱, 혹은 그밖에 해당 토큰으로 보호를 받는 리소스로 돌아갈 때마다 자격 증명을 다시 입력할 필요 없이 토큰이 발급된 웹 사이트나 액세스 할 수 있습니다.
토큰은 유저 정보를 암호화한 상태로 담을 수 있고, 암호화했기 때문에 클라이언트에 담을 수 있다.

JWT

JWT(Json Web Token)은 토큰 기반 인증 중 가장 대표적인 방법, JSON 포맷으로 사용자에 대한 속성을 저장하는 웹 토큰입니다.

<JWT 구조>

header : Header는 이것이 어떤 종류의 토큰인지(지금의 경우엔 JWT), 어떤 알고리즘으로 sign(암호화) 할지가 적혀있다. 이 JSON 객체를 base64 방식으로 인코딩하면 JWT의 첫 번째 부분이 완성된다.

payload: Payload에는 정보가 담겨 있습니다. 어떤 정보에 접근 가능한지에 대한 권한을 담을 수도 있고, 사용자의 유저 이름 등 필요한 데이터는 이곳에 담아 암호화시킨다. 물론 암호화(헤더에서 정의한)가 될 정보지만, 민감한 정보는 되도록 담지 않는 것이 좋다. 첫 번째 부분과 마찬가지로, 위 JSON 객체를 base64로 인코딩하면 JWT의 두 번째 블록이 완성된다.

signature: base64로 인코딩 된 첫 번째, 그리고 두 번째 부분이 완성되었다면(--> 이는 누구나 쉽게 decoding 할 수 있음), 원하는 비밀 키(암호화에 추가할 salt)를 사용하여 암호화한다(--> JWT가 스스로를 안전하다고 증명하는 이유이다!)

<JWT 인증 방식>

※순서※

1. 사용자가 로그인을 한다.
2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣습니다.
3. JWT 토큰의 유효기간을 설정합니다.
4. 암호화할 SECRET KEY를 이용해 ACCESS TOKEN을 발급합니다.
5. 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보냅니다.
6. 서버에서는 해당 토큰의 Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인합니다.
7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져옵니다.

Refresh Token

이미 발급된 JWT에 대해서는 돌이킬 수 없습니다.
유효기간이 완료될 때 까지는 계속 사용이 가능합니다.
따라서, 악의적인 사용자는 유효기간이 지나기 전까지 신나게 정보들을 털어갈 수 있습니다.

Refresh Token은 위에 문제를 해결을 할 수가 있습니다.
Refresh Token은 Access Token과 똑같은 형태의 JWT입니다. 처음에 로그인을 완료했을 때, Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서 Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됩니다.

<Access + Refresh Token 인증>

※순서※

1. 사용자가 ID , PW를 통해 로그인합니다.
2. 서버에서는 회원 DB에서 값을 비교합니다(보통 PW는 일반적으로 암호화해서 들어갑니다
3. 4번 과정
4. 로그인이 완료되면 Access Token, Refresh Token을 발급합니다. 이때 일반적으로 회원 DB에 Refresh Token을 저장해둡니다.
5. 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보냅니다.
6. 7번 과정
7. Access Token을 검증하여 이에 맞는 데이터를 보냅니다.
8. 시간이 지나 Access Token이 만료됐다고 보겠습니다.
9. 사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보냅니다.
10. 11번 과정
11. 서버는 Access Token이 만료됨을 확인하고 권한 없음을 신호로 보냅니다.
12. 사용자는 Refresh Token과 Access Token을 함께 서버로 보냅니다.
13. 서버는 받은 Access Token이 조작되지 않았는지 확인한 후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교합니다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해줍니다.

** Access Token 만료가 될 때마다 계속 과정 9~11을 거칠 필요는 없습니다.

 사용자(프론트엔드)에서 Access Token의 Payload를 통해 유효기간을 알 수 있습니다. 따라서 프론트엔드 단에서 API 요청 전에 토큰이 만료됐다면 바로 재발급 요청을 할 수도 있습니다.

Refresh Token이 들어가면서 과정이 좀 복잡해졌습니다. 하지만 Access Token의 약점을 보완해주기 때문에 보안이 중요한 프로젝트에서는 사용하기를 권장합니다.

---

이상으로 인증에 관해서는

간단하게 정리를 하였습니다!!
다음 게시물에서는 oAuth에 대해서 정리를 하여서
실습이랑 개념에 대해서 자세히 설명하겠습니다.

 

※참고※

https://hamait.tistory.com/416

HTTP 기본인증 (Basic authentication)

https://tansfil.tistory.com/58?category=475681

쉽게 알아보는 서버 인증 1편(세션/쿠키 , JWT)

https://velog.io/@devjade/Token-based-Authentication

Token-based Authentication