티스토리 뷰
본 내용에 들어가기에 앞서 웹을 사용할 때 발생하는 여러 데이터들이 어떤 방식으로 저장이 되고 관리가 되는지에 대해 설명을 하려고 한다.
웹 사이트를 이용하다보면 영구적으로 저장해야 하는 데이터가 있고, 그렇지 않은 데이터가 존재한다.
크롬 브라우저를 사용하는 사용자의 입장을 예로 들어서 몇가지를 설명하려고 한다.
-크롬 브라우저를 통해 구글 사이트에 접속한 뒤, 구글 계정에 '가입'을 한다고 가정해보자. 이 때 사용자는 아이디, 비밀번호, 이메일 등의 내용을 기입하게 된다. 이러한 데이터는 영구적으로 저장을 해야 하는 데이터이다. 브라우저를 껐다 다시 켰을 때, 컴퓨터를 종료한 뒤 다시 켰을 때마다 매번 가입을 해야한다면 구글을 이용하려는 사람은 없을 것이다. 이렇게 영구적으로 저장되어야 하는 데이터의 경우에는 클라이언트(브라우저)가 아닌 서버의 DB에 저장을 해야 한다. 그 후 로그인을 할 때마다 서버에 요청을 보내서 DB에 해당 계정이 있는지를 알아본 뒤 있으면 요청을 승인하도록 서버를 구현하면 된다.
-이번에는 채용 플랫폼인 '원티드', '사람인'을 방문했다고 가정해보자. 이런 채용 플랫폼에서는 보통 사용자가 원하는 조건에 맞춰서 구인 조건을 설정할 수가 있다. '서울, IT 업계, 경력 1년 이상' 이러한 조건을 설정했을 때, 해당 사이트를 이용하는 동안 지속적으로 조건에 맞는 채용 공고 위주로 출력을 해주게 된다. 하지만 이러한 정보는 영구적으로 저장이 되어야 하는 데이터는 아니다. 보통 이런 데이터는 로컬 또는 쿠키와 세션에 저장이 된다.
(물론 DB에 영구적으로 저장을 시킬수는 있다. 하지만 DB의 자원은 무한하지 않고, 데이터가 많을수록 성능에 문제가 생기기 때문에 무조건 영구적으로 저장하는 것은 좋지 않다.)
-그 외에도 크롬 브라우저는 검색 기록, 방문한 사이트를 저장하고 폰트 종류와 크기, 언어 종류 등 사용자의 성향에 맞춰서 커스터마이징을 할 수 있는 기능들을 제공한다. 이러한 정보들은 로컬에 저장되거나 쿠키와 세션에 저장이 된다. 또한 쇼핑 사이트에서 제공하는 장바구니의 경우에도 보통 쿠키와 세션에 저장이 된다.
하지만 요즘은 컴퓨터 뿐만 아니라 스마트폰으로도 웹 사이트 또는 웹 어플리케이션을 사용하기 때문에 이러한 영구적으로 저장할 필요가 없는 데이터들을 로컬 또는 쿠키 세션에 저장하기 보다는 클라우드를 통해 저장한 뒤 이러한 데이터를 연동하여 여러 기기에서도 사용할 수 있는 환경을 제공하기도 한다.
즉, 브라우저를 통해 웹 사이트를 이용하면서 발생하는 수 많은 종류의 데이터들 중에 영구적으로 저장해야 하는 데이터는 DB에 저장을 하고, 그렇지 않은 데이터들은 쿠키와 세션, 로컬, 클라우드 등에 저장을 하면 되는데, 이는 해당 데이터의 성격과 로컬, 쿠키와 세션 같은 저장 방식의 특성과 어플리케이션 운영 목적 등에 따라 선택을 하여 운영을 하면 된다.
쿠키와 세션
위에 작성한 데이터의 저장 방식을 토대로 쿠키와 세션에 대해서 간단하게 설명을 해보자면, 사용자가 웹(브라우저)를 이용하면서 발생하는 데이터들을 저장하는 방식이다.
방문 기록을 저장하고, 검색 기록을 저장하고, 장바구니의 내용을 저장하고, 사용자가 설정한 폰트 종류와 크기, 채용 플랫폼에 저장한 조건 등 웹을 사용하면서 생기는 수 많은 데이터들을 쿠키와 세션을 통해 저장하여 관리할 수 있다.
뒤에서 설명할 내용이지만 미리 언급하자면, 쿠키와 세션은 데이터를 저장하는 역할 외에도 다른 중요한 역할을 하는데 대표적으로 '인증'이다. 사용자가 구글 계정에 가입을 했을 때, 해당 데이터 자체는 서버의 DB에 저장이 될 것이다. 만약 구글 계정에 로그인을 한 뒤, 이메일을 보내려고 한다고 가정해보자. 이 때 구글 입장에서는 해당 사용자가 구글 계정에 가입한 사용자 라는 것을 인증되어야만 이메일을 사용할 수 있게 해놔야 할텐데, 이것을 어떻게 식별할 수 있을까?
(구글에 접속해서 수 많은 일들을 할 수 있는데 크게 분류해보자면 '구글 가입 없이도 할 수 있는 일', '구글 가입 없이는 할 수 없는 일' 두가지로 나뉠 것이다. 검색을 하고자 한다면 구글에 딱히 가입을 하지 않고도 가능 할 것이다. 하지만 이메일을 사용하고자 한다면 가입을 해야만 이용이 가능할 것이다. 즉, 지금 얘기하고자 하는 내용은 구글에 가입한 뒤 로그인을 했을 때만 이용 가능한 부분에 대한 얘기이다.)
이에 대해 알아 보기 전에, HTTP에 대한 간단한 설명을 먼저 해보려고 한다.
클라이언트가 서버에게 요청을 보낼 때 HTTP 규칙을 따르게 되는데, HTTP는 stateless 한 성격을 지니고 있다. 클라이언트가 서버에게 여러가지의 요청을 보낼 때 이 요청들끼리는 서로 영향을 주지 않는다는 뜻이다. 즉, 이메일을 사용하기 위해 로그인 요청을 보낸 뒤에 서버로부터 권한을 인정 받아 로그인이 되었다고 하더라도 이메일 버튼을 눌러서 페이지를 불러오는 요청과는 서로 영향을 주지 않는다는 뜻이다. 쉽게 말하자면 로그인 요청과 이메일 페이지 불러오기 요청은 서로 모르는 사이이기 때문에 원칙적으로는 로그인이 완료된 뒤에 이메일 페이지를 요청한다고 해도 이 사용자가 로그인을 한 사용자인지 아닌지를 판별할 수가 없어서 이메일 페이지를 보내줄 수가 없다.
이러한 문제를 쿠키와 세션이 해결을 해줄 수 있다. '쿠키 또는 세션'에 로그인을 유지하는 기능을 넣어둠으로써 로그인을 한 뒤에 이메일 요청을 했을 때 기존과는 달리 로그인이 유지되고 있기 때문에 이제는 이메일 페이지를 서버로부터 받아올 수 있고 이메일을 정상적으로 사용할 수 있게 된다. 즉, 쿠키와 세션을 통해 stateful 하게 만들어주는 것이다.
(쿠키 또는 세션에 넣어둔다고 설명은 했지만, 개인 정보와 같은 민감한 정보는 세션에 저장하여 관리하도록 하는 것이 좋다. 자세한 내용은 뒤에서 설명할 것이다.)
=> 요약하자면, 가입을 하고 로그인 하는 그 자체가 아닌, 그 이후에 로그인 한 상태를 지속적으로 확인하면서 사용자를 인증해 줄 방법이 필요한데, 이를 쿠키와 세션을 통해 해결할 수 있다는 것이다. 그리고 쿠키와 세션은 웹 사이트를 사용하면서 발생하는 여러 정보를 저장하고 관리하는 역할을 하지만, 이 외에도 로그인 유지를 해줌으로써 지속적인 인증을 제공하는 역할도 한다.
=> 그리고 쿠키와 세션의 역할에 대해 큰 범주로 다시 요약하자면, 쿠키와 세션은 웹을 이용하는 사용자가 사용하는 동안 발생한 데이터들을 저장해주는 역할을 하고, 사용자 인증을 통해 로그인 상태를 지속적으로 인증 해주는 역할을 한다.
*쿠키와 세션에 저장되는 데이터의 종류들
-5벌의 옷이 있고, 5권의 책들이 있고 옷장과 책 꽂이 서랍이 있다고 가정해보자. 일반적으로 이런 상황에서는 옷은 옷장에 넣고, 책은 책 꽂이 서랍이 넣을 것이다. 하지만 그렇다고 옷을 책꽃이 서랍에 넣고, 책을 옷장에 넣는게 불가능한 것은 아니다.
웹사이트를 사용하는 동안 발생하는 여러 종류의 데이터들이 있고 이들은 각자 쿠키 또는 세션에서 저장되고 관리가 된다. 이 데이터들도 옷과 책처럼 꼭 쿠키에 혹은 세션에 들어가도록 정해진 것은 없다. 하지만 일반적으로, 통상적으로 데이터의 종류의 특성에 따라 쿠키에서 저장하고 관리하거나, 세션에서 저장하고 관리되어야 하는 일종의 규칙은 존재한다. 쿠키와 세션의 성격을 이해하고 데이터 종류 마다 가진 특성을 통해 적절한 곳에 저장되고 관리되도록 해줘야 한다.
(앞서 설명했듯이 상황에 따라 쿠키와 세션이 아닌, 로컬 또는 클라우드에 저장을 하는 것도 가능하다.)
아래에 일반적으로 쿠키에 저장되는 내용과 세션에 저장되는 내용에 대해 정리를 해보려고 한다.
-쿠키에는 주로 사용자의 설정 및 기본 정보들을 저장한다.
1. 사용자가 설정한 언어에 대한 정보
2. 사용자가 웹 사이트의 디자인이나 색상 등을 설정한 정보
3. 사용자가 검색한 기록
4. 사용자가 방문한 페이지 기록
5. 사용자가 관심을 가지고 있는 제품이나 서비스에 대한 정보
6. 폰트 종류와 크기와 같은 정보
이러한 사용자 설정 및 기본 정보는 웹 사이트가 사용자의 선호도에 맞게 개인화되고 최적화된 경험을 제공하는 데 도움이 된다.
*앞서 이메일을 사용하기 위한 '사용자의 로그인 유지 기능'은 세션에 보관하는게 맞지만, 사용자가 로그인 할 때 옵션으로 선택할 수 있는 "로그인 상태 유지"를 활성화 시켰다면 이는 세션이 아닌 쿠키에 저장이 된다. 쿠키는 세션과 달리 브라우저를 종료하더라도, 컴퓨터를 종료하더라도 일정 기간 동안 데이터를 저장하고 있는 특성이 있기 때문에 쿠키에 저장하면 이렇게 로그인 상태 유지가 가능한 것이다. 이렇게 오랫동안 어떠한 데이터를 간직할 수 있게 하는 방식을 '영속적인 쿠키'라고 부른다. 매번 로그인 하기 귀찮을 때 이 옵션을 선택하는 사용자들이 많은데, 이런 민감한 정보를 쿠키에 저장하는 것은 보안상 취약할 수 있기 때문에 유의해야 한다.
-세션에는 주로 사용자 인증 및 보안 관련 정보들을 저장한다. 앞서 설명한 쿠키에 주로 저장되는 데이터들은 때에 따라 세션에 저장할 수도 있다. 하지만 '사용자의 로그인 유지 기능'은 세션에 저장하는 것이 보안상 더 안전하기 때문에 이를 염두해두는 것이 중요하다.
=> 즉, 쿠키와 세션에 저장되는 정보는 다양한데, 상황에 맞춰서 쿠키와 세션 각각에 저장되도록 설정하면 된다. 주의할 점은 '사용자의 로그인 유지 기능'에 대해서는 쿠키 보다는 세션에 저장하는 것이 좋다는 것이다.
*'사용자의 로그인 유지 기능'을 세션이 담당하게 되면 해당 사용자에게 고유의 세션 ID를 부여함으로써 지속적으로 해당 세션 ID를 확인해가면서 해당 사용자가 맞는지를 확인하게 된다. 세션 ID는 컴퓨터를 종료한 순간 사라지기 때문에 다음 날 다시 해당 웹 사이트를 접속했을 때 다시 로그인을 해야하는 것이고, 이 때 다시 세션 ID를 부여하게 된다.
*어떤 웹 사이트는 가입을 하지 않아 로그인 상태가 아니어도, 상품을 장바구니에 담을 수 있는 기능을 제공하는 경우가 있다. 이 때도 쿠키 또는 세션에 해당 정보를 저장할 수 있는데, 만약 세션에 저장한다고 가정한다면 사용자가 해당 웹 사이트를 방문하는 순간 고유의 세션 ID를 부여하여 로그인 상태가 아니어도 상품을 장바구니에 담을 수 있고 이후 다른 작업을 하고 다시 오더라도 그 장바구니 내역을 기억하게 할 수 있다.
(앞서 '로그인 유지'를 세션이 담당했을 때 사용자에게 고유의 세션 ID를 부여한다고 했는데, 로그인을 하지 않은 사용자를 상대로도 세션이 어떤 데이터를 기억하도록 설정을 했다면 이 때도 세션 ID를 통해 관리가 된다.)
*쿠키와 세션을 설정하는 방법
-데이터가 쿠키와 세션 중 어디로 저장될지는 코드를 통해 개발자가 구현하면 된다.
-쿠키의 경우 JS를 사용하여 만들고 싶다면 document.cookie을 통해 쿠키를 생성하여 특정 데이터를 쿠키에 저장하도록 구현하면 된다.
-세션의 경우 Node.js와 Express를 사용하여 만들고 싶다면 express.session 패키지를 통해 세션을 생성하여 특정 데이터를 세션에 저장하도록 구현하면 된다.
*쿠키와 세션이 '사용자 인증'을 통해 로그인을 계속 유지할 수 있도록 하는 방식이 이루어지는 과정을 설명해보려고 한다.
-클라이언트가 로그인을 하게 되면 서버는 DB에 저장된 아이디와 패스워드가 일치하는지 확인 후, 만약 유효한 사용자라면 세션을 생성한다.
-세션에는 사용자의 아이디와 세션 아이디와 세션이 얼마동안 유효한지에 대한 간직을 하게 된다. 세션은 서버에 저장이 되는데, 더 디테일하게 살펴보자면 DB에 저장되거나 파일의 형태로 저장되거나 메모리에 저장되게 된다.
(일반적으로는 DB에 저장이 된다.)
-이렇게 저장을 한 뒤 클라이언트에게 세션에 대한 정보를 쿠키에 담아 보내준다. 이 때 HTTP only 옵션을 사용하게 되면 브라우저에서만 보이고 JS 코드에서는 보이지 않기 때문에 좀 더 안전하게 보낼 수 있게 된다.
-그 후 이제 클라이언트가 서버에게 어떤 요청을 할 때 쿠키를 같이 보내주게 되는데 쿠키에는 세션 아이디가 담겨 있고 서버에서 이 세션 아이디가 현재 세션 DB에 있는지를 판단 후 있다면 아 얘가 맞구나 판단하여 원하는 데이터를 클라이언트에게 주게 된다.
-이렇게 쿠키를 서버에게 보내게 되면 사용자에 대한 정보를 보내는게 아니라 세션 아이디를 통해 보내지게 되므로 안전성이 높다.
-이렇게 세션을 이용하게 되면 DB에 세션이 있어야만 보내주기 때문에 신뢰도가 높다. 그리고 쿠키를 사용하기 때문에 간단하다. 또한 HTTP only 덕에 안전하다.
*HTTP only 옵션을 사용하면 좋은 이유
-'크로스 사이트 스크립팅(XSS, Cross-Site Scripting)'을 방지할 수 있다. 크로스 사이트 스크립팅이란, 웹 페이지에 악성 스크립트 코드가 포함되어 사용자의 브라우저를 통해 공격이 수행되는 것을 의미한다.
공격하려는 자가 웹 페이지에 악성 JS 코드를 삽입하여 웹 페이지를 방문한 사용자의 쿠키나 세션 정보를 가로채거나, 조작하는 공격이다. 이렇게 사용자의 쿠키 정보를 가로챈 뒤, 사용자를 가장하여 서버에 악의적인 요청을 보낼 수 있게 된다.
이를 HTTP only 옵션을 사용함으로써 방지할 수 있다.
*쿠키와 세션의 차이점 정리
1. 저장 위치
-쿠키는 클라이언트(브라우저)에 저장이 된다. 쿠키를 통해 사용자를 식별하게 된다.
-세션은 서버에 저장이 된다. 세션 ID가 부여 되면서 이를 통해 사용자를 식별하게 된다.
*쿠키와 세션에 각각 저장되는 데이터들 또한 클라이언트 또는 서버에 저장이 된다.
2. 보안성
-쿠키는 클라이언트에 저장이 되기 때문에 보안이 상대적으로 취약하다. 민감한 정보는 쿠키에 담지 않는게 좋다.
-세션은 서버에 저장이 되기 때문에 보안이 상대적으로 좋다. 민감한 정보는 세션에 담는게 좋다.
(그러나 세션의 경우 서버의 리소스를 사용하므로, 많은 사용자가 동시 접속 하는 경우엔 서버 과부하가 발생할 우려가 있다.)
3. 데이터 유지 기간
-쿠키 만료 날짜를 설정할 수 있다. 만료 날짜를 설정하지 않았다면, 브라우저가 종료될 때 자동으로 삭제된다.
-일정 시간 동안 사용자가 활동하지 않으면 세션은 종료되며 데이터가 삭제된다. 그리고 로그아웃 하거나 서버가 재시작 되면 세션은 종료된다.
4. 저장 공간
-쿠키를 저장하는 공간은 상대적으로 작다.
-그에 비해 세션을 저장하는 공간은 상대적으로 크다.
=> 이러한 쿠키와 세션의 차이를 이해한뒤, 데이터의 성격에 따라 쿠키에 저장할지, 세션에 저장할지를 선택하면 된다.
*세션 / 쿠키 단점
-stateful이다. 상태가 존재하기 때문에 만약 다른 서버를 같이 사용하고 있는 경우 이 세션이 저장된 서버를 거칠 수 밖에 없어진다. 고로 네트워크 요청 과정이 추가되고 복잡해진다.
=> 이러한 이유 때문에 요즘에는 쿠키와 세션을 통해 사용자 인증을 구현할 때 JWT를 많이 사용한다.
OAuth
*OAuth란?
-"소셜 로그인" 또는 "소셜 계정으로 가입"이라고도 불린다.
각 소셜 플랫폼에서 제공하는 OAuth 인증 방식을 통해 사용자의 동의를 받고, 서비스에 필요한 사용자 정보를 안전하게 가져올 수 있다. 이를 통해 사용자는 별도의 계정을 만들 필요 없이 소셜 계정을 사용해 원티드와 같은 서비스에 간편하게 가입하거나 로그인할 수 있다.
(원티드와 같은 웹 사이트에서 구글, 네이버, 카카오톡 등의 계정을 사용하여 가입하거나 로그인할 수 있는 기능은 OAuth를 통해 구현되는 것이다.)
OAuth를 이용한 소셜 로그인은 개발자들이 직접 사용자의 인증 정보를 관리할 필요가 없어 보안성이 높아지며, 사용자들에게도 편리한 사용 경험을 제공할 수 있기 때문에 많은 서비스에서 활용되고 있다. 대신, 사용자가 동의한 범위 내에서만 사용자 정보에 접근할 수 있는데, 이를 통해 사용자의 프라이버시와 보안을 보장할 수 있다.
즉, OAuth는 두 개 이상의 애플리케이션 간에 안전하게 정보를 교환할 수 있는 방식을 제공하는 것이다.
*OAuth를 사용한 인증 과정을 ‘미래의 SNS’라는 웹 어플리케이션 로그인 과정을 통해 알아보자.
-'미래의 SNS' 웹 애플리케이션에 방문한 뒤 가입을 할 때 홈페이지 자체에 계정을 가입하는 것이 아니라, 구글 또는 카카오톡 또는 네이버 등의 선택지 중에 원하는 계정을 통해 가입을 한다. 구글 계정을 통해 가입한다고 가정해보자.
-구글 버튼을 클릭하면 사용자를 구글 로그인 페이지로 리다이렉트시킨다. 이때, 애플리케이션에 대한 정보와 요청하는 권한 범위(scope)를 포함한 요청이 함께 전달된다.
-사용자가 만약 구글 계정으로 로그인한 후, '미래의 SNS' 애플리케이션에서 요청한 권한 범위를 확인하고, 그에 대한 동의를 한다.
-동의를 완료하면, 구글은 '미래의 SNS' 애플리케이션으로 사용자를 다시 리다이렉트시키며, 이 과정에서 authorization code를 전달한다.
-'미래의 SNS' 애플리케이션은 authorization code와 함께 구글로 요청을 보내어 access token과 refresh token을 받는다.
-'미래의 SNS' 애플리케이션은 access token을 사용해 구글 API에 요청하여 사용자 정보를 받아온다. 이를 통해 구글 계정을 사용하여 로그인한 사용자의 정보와 권한을 확인할 수 있다.
JWT
*쿠키와 세션의 역할이었던 '로그인 상태 유지'를 JWT를 통해서도 구현할 수 있다. 실제로 요즘에는 쿠키와 세션 보다는 JWT를 많이 사용하는 추세인데, 대표적인 이유로는 쿠키와 세션을 사용하면 기존 HTTP의 특성이었던 stateless를 stateful하게 만들어주는데, 이렇게 하면 분산형 서버를 만들었을 때 서버 간에 서로 검증이 이루어져야 하기 때문에 복잡하고 서버 한 군데에 문제가 생기면 원활하게 웹 어플리케이션이 동작하지 않을 수 있게 된다. 반면 JWT의 경우는 애초에 stateless 한 상태이면서 '로그인 상태 유지' 까지 해주기 때문에 이러한 이유로 JWT를 많이 선호하게 되었다.
*JWT는 클라이언트와 서버 간에 정보를 안전하게 전송하고 사용자 인증 상태를 유지하는데 사용되는 토큰이다. 프로젝트 만들었을 때, 가입을 하거나 로그인을 하는 그 로직 자체는 내가 코드로 직접 구현을 한 것이고, 토큰을 유지시킴으로써 인증된 사용자만 어플리케이션을 사용하도록 해주는 것은 JWT의 역할이다.
=> 다시 한 번 요약하자면, 특정 웹 어플리케이션에서 가입한 사용자만 이용할 수 있도록 했을 때 쿠키와 세션, JWT는 사용자를 인증시킴으로써 이를 가능하게 해준다.(요새는 JWT를 더 많이 사용)
*JWT는 Json Web Token의 약자이다. 이름에서 알 수 있듯이 Json의 형식을 사용해서 서버와 클라이언트가 웹 토큰을 주고 받는다.
*JWT의 Json 안에는 'header, payload, signature'이 있는데 여기에는 사용자에 대한 auth의 정보가 담겨 있고 이를 클라이언트와 서버가 서로 주고 받게 된다.
(Json 안에 담겨진 사용자에 대한 정보는 인코딩이 되어 있기에 타인이 쉽게 무엇인지 알아차리기가 어렵다. 또한 signature 안에 secretkey라는걸 통해 인코딩을 시키기 때문에 더더욱 악의적인 접근이 불가능하다.)
*JWT를 생성하고 주고 받는 과정
-클라이언트가 로그인 하면 DB에 저장된 아이디, 패스워드가 일치하는지 확인 후 일치한다면 JWT를 만들게 된다.
-그럼 JWT를 사용자에게 보내주고 그 후 추후 클라이언트가 요청하는 모든 API에 대해서 받은 JWT를 헤더에 포함시켜서 보내게 된다.
-그럼 서버는 JWT가 유효한건지 확인하고 요청에 대해서 처리를 해준다.
*JWT의 단점
-사라지지 않는 영원한 JWT를 생성한 경우 해커가 이를 해킹 할 위험성이 존재한다. JWT는 Node.js의 경우, JWT 패키지를 다운로드 받아서 사용하면 되는데, 이 때 JWT 토큰의 유효 기간에 대해 설정을 해줄 수 있기에 보안을 염두하여 꼭 유효 기간을 설정해야 한다.
*OAuth와 JWT가 각각 어떤 역할을 하는지에 대해서 정확히 아는 것이 중요하다.
*그리고 OAuth와 JWT는 서로 보완재로 사용될 수 있다. 예를 들어 OAuth를 통해 인증 후 JWT로 발급된 토큰을 사용하여 인증 상태를 유지하는 방식으로 활용할 수 있다.
*결론적으로, 쿠키와 세션은 사용자가 웹을 사용하는 동안 발생한 정보와 로그인 상태 유지를 위한 로그인 인증이라는 2가지의 역할을 한다. 이 때 로그인 상태 유지를 위한 로그인 인증은 JWT를 통해서도 구현이 가능하고 이 부분에 있어서 쿠키와 세션 보다는 JWT를 사용하는 것이 더 좋다. 마지막으로 OAuth는 어떤 웹 사이트를 방문하여 가입을 할 때 그 웹 사이트 자체에 새로운 계정을 만들기 보다는 구글이나 네이버 또는 카카오톡 같은 기존에 존재하던 '다른' 웹 사이트 혹은 웹 어플리케이션의 계정을 통해 가입을 진행할 수 있게 해주는 역할을 한다.
'기술 노트' 카테고리의 다른 글
| IPC란? (0) | 2023.07.02 |
|---|---|
| 서버 트래픽 과부하에 대한 예방과 대처 방법 (0) | 2023.05.07 |
| Node.js의 '특징'과 '동작원리' 그리고 JS의 '동작원리' (0) | 2023.04.08 |
| DB Index란? (0) | 2023.03.28 |
| 컴퓨터의 구조와 OS의 관계 (0) | 2023.03.21 |