Web(2)

seul_velog·2022년 9월 4일

웹 서버와 WAS의 차이점

웹 서버란 클라이언트가 웹 브라우저에 어떤 페이지 요청을 하면 웹 서버에서 요청을 받아 정적 컨텐츠(HTML문서, CSS, JS, 이미지, 파일 등)를 제공하는 서버이다.
WAS는 웹 서버와 웹 컨테이너가 합쳐진 형태로서, 웹 서버 단독으로는 처리할 수 없는 데이터베이스의 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공한다.

Web Server

웹 서버는 소프트웨어와 하드웨어로 구분된다.

하드웨어 → Web 서버가 설치되어 있는 컴퓨터
소프트웨어 → 웹 브라우저 클라이언트로부터 HTTP 요청을 받아 정적인 컨텐츠(.html .jpeg .css 등)를 제공하는 컴퓨터 프로그램

Web Server의 기능

HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스 한다.
웹 서버는 동적 컨텐츠를 요청 받으면 WAS에게 해당 요청을 넘겨주고 WAS에서 처리한 결과를 클라이언트에게 전달해 주는 역할도 한다.

WAS

인터넷 상에서 HTTP 프로토콜을 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어이다.
DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server 이다.

📌 웹 컨테이너 : 웹 서버가 보낸 JSP(Java Server Pages), PHP(Hypertext Preprocessor) 등의 파일을 수행한 결과를 다시 웹 서버로 보내주는 역할을 한다.

Web Server와 WAS

❓ 무조건 WAS만 쓰는 것이 좋을까?

클라이언트에 정적인 컨텐츠(ex. 이미지파일)을 보내는 과정을 예로 들자면, Web Server를 통해 정적인 파일들을 Application Server까지 가지 않고 앞단에서 빠르게 보내줄 수 있으므로 Web Serber에서는 정적 컨텐츠만 처리하도록 기능을 분배해서 서버의 부담을 줄일 수 있다.

❓ WAS가 필요한 이유

웹 페이지에는 정적 컨텐츠와 동적 컨텐츠가 모두 존재하는데, 사용자의 요청에 맞는 데이터를 DB에서 가져와서 비즈니스 로직에 맞게 동적으로 그때 그때 결과를 만들어서 제공함으로써 자원을 효율적으로 사용할 수 있다.

❓ Web Server와 WAS 분리하는 이유

자원 이용의 효율성 및 장애극복, 배포 및 유지보수의 편의성을 위해 Web Server와 WAS를 분리한다.

OAuth

OAuth는 별도의 인증에 대한 구현없이 기존 사용자들이 보유한 Naver, Google 등의 ID를 이용해 권한을 획득하도록 도와준다. 즉, 외부 서비스에서도 인증을 가능하게 하고 그 서비스의 API를 이용하게 해준다.
사용자들의 입장에서는 별도의 가입없이 바로 사용이 가능케하며, 어플 제작사나 웹사이트 운영자들의 입장에서는 인증을 위한 별도의 구현을 하지 않아도 되게 해준다.
간단하게 인증(Authentication)과 권한(Authorization)을 획득하는 것으로 볼 수 있다.

OAuth는 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.

OAuth의 배경

third party Application에 아이디와 비밀번호를 제공하고 싶지않은 심리
여러 애플리케이션에 ID/PW를 계속해서 제공할 경우 피싱에 둔감
Application이 안전하다는 보장이 없으므로 보안에 취약

Oauth 1.0

하지만 Oauth 1.0은 구현이 복잡하고 웹이 아닌 어플리케이션에서의 지원이 부족했다. 또 일반적으로 OAuth 1.0 액세스 토큰은 1년 이상 보관할 수 있다고 한다. (Twitter는 만료시키지 않음).

Oauth 2.0

달라진 점

기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어 졌다
OAuth 2.0 은 JWT Bearer 토큰 인증방식을 사용하여 signature가 필요없어져서 간단해졌다.
HMAC 암호화만 사용하던 1.0과는 다르게 여러가지 인증방식을 제공하여 시나리오, 브라우저별로 대응할 수 있다.
큰 서비스를 하기 위해서는 인증서버 분리, 인증서버 다중화가 되어야하는데 2.0은 인증부분을 분리함으로서 인증서버가 다중화될 수 있게 되었다.

📌 Oauth 2.0과 Authorization & Authentication

OAuth 2.0 은 Authorization(권한 획득)을 위한 protocol이지, Authentication(인증)을 위한 protocol이 아니다.
각기 서비스 제공자가 수행한 Authentication(인증)을 바탕으로 Authorization(권한 획득)된 token을 가지고 서비스를 이용할 수가 있는 것이다.

+) Oauth 2.0 기반의 PAYCO 로그인 및 회원가입 인증과정 & 프로레스 참고 👇

JWT(JSON Web Token)

유저 정보를 담은 JSON 데이터를 암호화 해서 클라이언트와 서버간에 주고 받는 것으로, JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다.
현대 웹서비스에서는 토큰을 사용하여 사용자들의 인증 작업을 처리하는 것이 가장 좋은 방법이며, JWT는 토큰 기반의 인증 시스템에서 주로 사용된다.

JWT(Json Web Token)란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다.
JWT는 Claim 기반이라는 방식을 사용하는데, Claim이라는 사용자에 대한 프로퍼티나 속성을 말한다.
→ 토큰 자체가 정보를 가지고 있는 방식으로, JWT는 이 Claim을 JSON을 이용해서 정의 한다.

Claim 기반

📌 Claim을 JSON으로 나타낸 예시)

JSON자체를 토큰으로 사용하는 것이 Claim기반의 토큰 방식이다.

{
    "id":"terry"
    ,"role":["admin","user"]
    ,"company":"pepsi"
}

❓ Claim 방식의 토큰은 무엇이 좋을까?
→ 이 토큰을 이용해서 요청을 받는 서버나 서비스 입장에서는 이 서비스를 호출한 사용자에 대한 추가 정보는 이미 토큰 안에 다 들어가 있기 때문에 다른 곳에서 가져올 필요가 없다!

✍️ Claim 기반의 토큰은 토큰 자체가 정보를 담음으로써, 토큰을 가지고 서비스나 API 접근을 제어할 때 별도의 작업이 서버에서 필요하지 않으며, 토큰 자체를 서버에서 관리할 필요가 없기 때문에 구현이 상대적으로 단순해진다!

JWT의 문제점

사용이 쉽고, 서버의 개발 부담을 덜어줄 수 있다는 장점을 가지고 있지만 단점 또한 존재한다.
1) 길이
: Claim에 넣는 데이터가 많아질수록, JWT 토큰의 길이가 길어진다. 길이가 길다는 것은 그만큼 네트워크 대역폭 낭비가 심하다는 의미이다.

2) 한번 발급된 토큰은 값을 수정하거나 폐기가 불가
: JWT는 토큰 내에 모든 정보를 가지고 있으므로 한 번 발급된 토큰에 대한 변경은 서버에서는 더이상 불가능하다. 때문에 만약 JWT를 쓴다면, Expire time을 꼭 명시적으로 두도록하고, refresh token등을 이용해서, 중간중간 토큰을 재발행하도록 해야한다.

3) 보안
JWT는 기본적으로 Claim에 대한 정보를 암호화하지 않는다. 특히 자바스크립트 기반의 웹 클라이언트의 경우 브라우저상의 디버거등을 통해서 토큰이 노출될 가능성이 높다.
그래서, 이를 보완하는 방법으로는 토큰 자체를 암호화하는 방법이 있는데, JSON을 암호화하기 위한 스펙으로는 JWE(JSON Web Encryption)이 있다고 한다. 🧐

Authentication and Authorization

Authentication(인증) & Authorization(권한 획득)
인증 : 인증은 시스템 접근을 확인하는 것이다. (로그인)
권한 : 권한은 행위의 권리를 검증하는 것이다.
예를 들면 사용자가 ID와 Password 입력을 통해 Authentication(인증)을 진행하면 그 대상 사이트(혹은 앱)에 대한 Authorization(권한 획득)을 할 수 있게 되는 것이다.

Authentication(인증)

인증은 사용자의 신원을 검증하는 행위로서 보안 프로세스에서 첫 번째 단계이다.

인증 프로세스

비밀번호
: 사용자 이름과 비밀번호는 가장 많이 사용되는 인증 요소이다. 사용자가 데이터를 올바르게 입력하면 시스템은 아이덴티티가 유효하다고 판단하고 액세스를 허용한다.
일회용 핀
: 단일 세션이나 트랜잭션에 한하여 액세스를 허용한다.
인증 앱
: 액세스를 허용하는 외부 기관을 통해 보안 코드를 생성한다.
생체인식
: 사용자가 시스템에 액세스하기 위해 지문이나 망막 스캔을 제출한다.

상황에 따라 인증 요소를 2가지 이상 성공적으로 확인해야만 시스템에 액세스할 수 있는 경우도 있는데, 이러한 다중 요소 인증(MFA) 요건이 배포되어 비밀번호의 한계를 넘어 보안을 강화하는 경우도 많다.

Authorization(인가)

Authorization은 유저가 요청하는 request를 실행할 수 있는 권한이 있는 유저인가를 확인하는 절차이다.

시스템 보안에서 인가란, 사용자에게 특정 리소스나 기능에 액세스할 수 있는 권한을 부여하는 프로세스를 말힌다. 이 용어는 흔히 액세스 제어나 클라이언트 권한을 서로 대체하여 사용되기도 한다.
대표적으로, 서버에서 특정 파일을 다운로드할 수 있는 권한을 부여하거나, 개별 사용자에게 관리자 권한으로 애플리케이션에 액세스할 수 있는 권한을 부여하는 경우가 여기에 해당한다.
보안 환경에서 권한 인증은 항상 인증 이후에 진행되어야 힌다. 사용자가 먼저 자신의 자격 증명을 입증하면 기업의 관리자가 해당 사용자에게 요청한 리소스에 액세스할 수 있는 권한을 부여한다.

WebServer와 WAS
codechasseur
WebApplicationServer
OAuth
namuwiki-Oauth
technote
okta
westudy
JWT