나는 평소에 '아모레퍼시픽'에서 화장품을 많이 삼
(거의 아모레의 노예라고 할 수 있음)
그도 그럴것이 브랜드가 무지하게 많음.
💡 요즘엔 통합쇼핑몰이 많이 생겼지만, 과거에는 브랜드별로 각각 사이트에 회원가입을 해야 구매할 수 있었음
그러니깐 👧🏻 '설화수에서 엄마꺼 영양크림 사고, 프리메라에서 내 에센스사고, 이니스프리에서 동생 선크림사고, 일리윤에서 바디로션 사고, 에스쁘아에서 파운데이션을 사려면 각각 홈페이지에 회원가입을 해야했다.' 그래서 등장했다 !
올리브여...ㅇ아 아니라
통합회원으로 회원 DB를 정리하기 시작했다. 그래서 브랜드 홈페이지에 한 번 가입하면 다른 브랜드를 또 이용할 때 회원가입을 별도로 하지 않아도 된다.
아니잇 ! 귀찮다고 ! 옛따 소셜로그인
소셜로그인을 이해하려면, OAuth 2.0 도입에 대해 알고가야함(그렇다고 함)
OAuth 2.0을 이해하려면 먼저 알아야 할 개념이 있찌...
- Resource owner(자원 소유자-사용자)
- Client(서비스 제공자)
- Authorization server(인증을 처리하고 토큰을 발행하는 서버)
- Resource server(자원 제공 서버)
진짜 하기 싫은데, 해야지. 해내야지. 일어나 앉아
인증서버와 자원서버는 인증기능을 제공하는 기업(예시: 구글)에 존재
클라이언트('가영인가영'서비스 출시함), 인증기업(구글)에게 사용신청
사용신청서
기업체명: 나는가영
요청주소: www.가영인가영.com (로그인 성공시 접속할 주소 설정)
신청항목: 소셜로긴
요청항목: 아이디, 닉네임, 이메일 등등인증기업(구글): 오.......얘네 불법사이트 아니지? 오케 오케 적합하니까 승인!
사용자: (가영인가영 방문)'우헤헤헿 엇 소셜로그인 해야지~~'
클라이언트(가영인가영): 인증 서버(구글)로 안내
사용자: 인증서버에서 로그인을 시도
[처음 소셜로그인하는 경우]
인증서버는 클라이언트(가영인가영)가 요청했던 항목을 바탕으로 정보를 알려주고 동의 여부를 물음
사용신청서
기업체명: 나는가영
요청주소: www.가영인가영.com (로그인 성공시 접속할 주소 설정)
신청항목: 소셜로긴
요청항목: 아이디, 닉네임, 이메일 등등동의하면, 로그인에 성공 & 클라이언트(가영인가영)에게 해당 회원의 토큰을 발행
cf) 토큰(token)
- 서버의 응답 중 괄호안에 있는 부분이 토큰
- access_token: 자원 서버에서 사용자 정보를 불러오기 위한 랜덤한 문자열
- token_type: 토큰 유형을 나타냄(OAuth 방식의 경우 Bearer유형으로 표기)
- expire-in: 생성된 시점부터 지정된 시간(초 단위)만큼 사용할 수 있음
- refresh_token: 시간이 만료된 경우 리프레쉬 토큰을 사용해 access_token을 재발급 가능
클라이언트(가영인가영)는 전달받은 토큰(access_token)으로 자원 서버(구글)에서 사용자의 정보를 요청
자원서버(구글)는 인증토큰이 유효한지 확인 후에 요청한 정보(아이디, 닉네임, 이메일 등등)를 클라이언트(가영인가영)에게 전달
OAuth인증 절차 끝 !
클라이언트는 사용자의 정보 획득!
✋잠깐 ! 인증(Authentication)? 인가(Authorization)랑 다른건가? 아쉽게도 그러함😂
- 인증? 사용자의 신원을 확인하는 절차
- 인가? 사용자의 권한을 확인하고 허가하는 절차(인가는 인증 절차를 거친 후에 진행)
그러니깐, 서울대학교에 입학을 하고 학생증을 발급받는 과정이 '인증'이고, 그 학생증을 가지고 도서관에 출입하는 과정이 '인가'
❓❓❓❓이 부분은 다른 인증방법에 대한 추가 설명에 해당하므로, 관심이 없는 사람은 여기누르세요!
인터넷에서 인증과 인가는?
✅ HTTP(인터넷에서 데이터를 주고 받을 수 있는 프로토콜)
클라이언트(브라우저) -> request / response <- 서버
- request 클라이언트가 서버에게 데이터를 요청할 때 보내는 폼
- response 클라이언트에게 request가 들어왔을때 응답해주는 폼
아, 여기서 궁금한 점 !
그럼 서버는 내가 과거에 request했던 내용을 다 기억하고 있을까?
Stateless(무상태성), HTTP통신에서 서버는 현재요청과 이전요청의 맥락을 기억하지 못함'
클라이언트 '야 ! 서버 나 가영이다 !'(request)
서버 '아, 그래 가영이 왔냐 !'(response)
며칠후
클라이언트 '야 ! 서버 뭐하냐 !'(request)
서버 '예? 누구신데 반말이시죠 ?'(response)
그래서,
클라이언트 "야 ! 서버 나 '가영'이라고 하는데 반갑다 !"(request)
서버 "아 ! 가영이구나 ! 앞으로도 계속 '가영'이라고 이름표를 붙여서 와줘"(response)
며칠후
클라이언트 www.가영인가영.com/가영 - "야 ! 서버 잘지냈어? "
서버 이름표(/가영)를 확인 "어 ! 가영아 오랜만이다 !"
이런식으로 다음에도 기억해야 할 상태(정보)가 있다면 정보 이름표(url)가 점점 길어질 수 밖에 없음
단점
문제점 1. 개인정보가 담긴 url
문제점 2. 각 url에 해당하는 html 페이지를 생성하므로 서버 부하 가중
문제점 3. 다른 사이트 이동 혹은 로그아웃 시 기존의 데이터가 삭제됨
ㅇㅋㅇㅋ 그럼 이제
✅ IP주소를 통한 식별 방식을 해보자
클라이언트 request 헤더에 ip주소를 담아서 요청
서버 ip주소를 보고 식별
엥? 그런데 만약에 내 컴퓨터에서 동생이 접속한다면?
서버는 모름...
단점
문제점 1. 컴퓨터의 식별자이므로 사용자를 식별할 수 없음
문제점 2. 동적으로 IP주소를 할당하므로 바뀔 수도 있음
문제점 3. 방화벽, 프록시, 게이트웨이 등으로 실제 클라이언트의 IP주소를 알기 어려움
✅ HTTP 기본 인증방식은 어때?
1. 사용자에 대한 정보를 전달하는 헤더의 종류
From: 사용자의 이메일 주소
User-Agent: 사용자의 브라우저
Refere: 사용자가 현재 링크를 타고 온 근원 페이지
Authrization: 사용자 이름과 비밀번호- HTTP기본 인증방식은 'Authrization: 사용자 이름과 비밀번호'헤더를 사용
2. HTTP기본 인증방식 'Authrization'은
- 클라이언트가 www.가영인가영.com에 접속
- 서버는 접근 권한이 있는 사람만 들어올 수 있어. 그러니까 서비스에 인증된 회원인지 알려줘
- 클라이언트는 user name, password 등을 입력 - BASE64 encode - 해당 인코딩 값을 Authrization헤더에 담아서 전달
- 서버는 인코딩 된 값을 디코딩해서 클라이언트가 누구인지 인증하고 인증되면 www.가영인가영.com에 접속허용 응답을 함
단점
문제점 1. 사용자 이름과 비밀번호를 쉽게 디코딩할 수 있음
문제점 2. 재전송 공격을 예방하지 못함
문제점 3. 가짜 서버의 위장에 취약
후....그냥 하지마 때려치워
✅ '쿠키 with 세션방식' 진짜 이거로하자
1. 쿠키
- 브라우저에 저장되는 키와 값이 들어있는 데이터 파일
- 클라이언트의 상태 정보를 저장
- 사용자가 따로 요청하지 않아도 Request시 Header에 담겨 서버에 전공
2. 세션
- 쿠키와 달리 서버 측에서 관리
- 클라이언트를 구분하기 위해 세션 ID부여
- 세션 ID를 통해 클라이언트 식별
자, 그럼 통신 구조를 보자면
(지친)클라이언트: username, password를 header에 담에서 로그인(request)
서버
- 요청받은 username, password로 우리 서버의 인증된 회원인지 확인
- 확인되면 세션ID를 생성하고 세션 저장소에 저장해둠
- 세션ID를 쿠키에 담아서 클라이언트에 전달(response)
며칠후
클라이언트: 쿠키를 가지고 있다가 다음 요청시 쿠키와 함께 다시 요청
서버: 쿠키에 담긴 세션ID와 세션저장소에 담긴 세션 ID를 비교해서 사용자 인가여부를 결정
단점
문제점. 다중서버의 환경이라면?
- A서버에서 세션ID를 발급받아 해당 세션저장소에는 저장이 되었는데
- 다중 서버 환경이라면? 세션 불일치 문제가 발생 !
해결방안 1. sticky session: 로드밸랜서가 클라이언트의 요청을 세션을 생성한 서버로만 전달
해결방안 2. session clustering: 모든 서버의 세션 동기화
해결방안 2. 별도의 세션 저장소 생성: Redis, Memcached 등
하.지.만 확장성이 떨어진다는 문제점은 해결하지 못함
✅ 토큰기반 인증방식(JWT)어떤가요?
JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token(인증에 필요한 정보들을 암호화시킨 JSON 토큰)
1. 구조
- Header: 토큰의 타입, 해싱 알고리즘
- Payload: Claims(사용자의 정보가 담겨있음)
- Signiture: header, payload를 합친 문자열을 서버의 비밀키와 함께 암호화한 값
2. 통신방법
클라이언트는 username, password로 로그인을 요청
서버 인증절차를 거친 후 클라이언트에게 토큰을 발급
클라이언트는 토큰을 가지고 있다가 Authorization 헤더에 해당 토큰을 가지고 다시 요청
서버는 해당 비밀키로 무결성을 검증하고, 토큰의 유효성을 검증하고, 유저를 인가
3. 특징
- 서버 기반 인증 시스템과 달리 상태를 유지하지 않는다.
- DB를 조회하지 않고 인증된 회원인지 식별할 수 있다.
4. 문제점
- 쿠키, 세션과 다르게 토큰 자체의 데이터 길이가 길다
- payload는 암호화되지 않기 때문에 유저의 중요한 정보를 담을 수 없음
- 토큰을 탈취 당하면 대처가 어렵다
🌼돌아와 이제 OAuth2.0으로🌼
- 만약에 클라이언트(브라우저)사이트가 해킹된다면? 구글계정은?
- 만약에 클라이언트(브라우저)사이트가 악의적인 사이트라면?
- 클라이언트(브라우저)도 마찬가지로 민감한 구글 계정 정보의 보관이 부담스러울 수 있음
- 구글도 회원정보를 클라이언트(브라우저)에게 내주는게 괜찮을지 걱정됨
OAuth(인가에 대한 기술)
웹, 모바일, 데스크탑 어플리케이션에서의 간단하고 표준적인 방법으로 보안 인가를 허용하기 위한 개방형 표준 프로토콜
OAuth 2.0은 뭐지?
- 원래 제일 처음에 OAuth 1.0이 개선되어 OAuth 1.0a로 현재 가장 최신 버전인 OAuth 2.0 버전이 있음(1.0버전과 2.0버전은 호환되지 않음)
- 자자, 잊었을거 같아서 복습(올려서 찾기 귀찮으니깐...크킄)
1. Resource owner(자원 소유자-사용자)
2. Client(서비스 제공자)
3. Authorization server(인증을 처리하고 토큰을 발행하는 서버)
4. Resource server(자원 제공 서버)최종(진짜최종)_진짜진짜최종(완전끝).hwp
사용자(Resource owner): 리소스를 소유하며 접근할 권한을 가지고 있고, 클라이언트에게 그 권한을 위임하는 주체(인증을 수행하는 주체)
웹브라우저(Client): 리소스 소유자 대신 위임 받은 권한으로 리소스를 요청하는 주체(권한을 위임받는 주체)구글
- Authorization server - 리소스 소유자를 인증하고 클라이언트에 액세스 토큰을 발금하는 서버(인증을 검증하고 권한을 부여하는 주체)
- Resource server - 액세스 토큰을 사용하여 리소스 요청을 수락하고 응답할 수 있는 리소스를 가지고 있는 서버(인가를 수행하고, 리소스를 부여하는 주체)
- 참고) scope? 클라이언트에게 허용된 리소스 접근 범위
자세히 보면
-
사용자가 구글에 접근해서 아이디와 패스워드를 통해 인증을 받고
-
권한은 클라이언트가 받음(클라이언트는 권한을 인증받는 어느 과정에서도 관여하지 않음- 보안을 위함)
다음 접속할때는?
- 사용자가 클라이언트에 서비스 요청을하면, 클라이언트가 리소스서버에 저장된 토큰으로 리소스 요청을하고, 저장된 토큰과 일치하면 리소스를 제공함
- 그러면 클라이언트는 서비스를 제공!
실제 구현은 다음기회에...뱌뱌
추가
예전에 했던 팀프로젝트에서 구글로그인을 했었나? 찾아보던 중에 네이버랑 카카오 로그인했던거 발견..........
내 생에 첫 프로젝트 였음
나는 그 당시에 로그인과 회원가입 페이지를 맡음
코드는 엉망진창이긴함(리액트 안배운 상태에서 리액트로 프로젝트함ㅋㅋ)..... 그렇지만 생각보다 잘했음ㅋㅋ
백엔드 서버도 배포했었는데 헤로쿠여서 볼 수 없지만(그래서 유효성검사, 중복확인 기능은 다 살아있는데, 회원가입은 안됨), 프론트 배포는 아직 볼 수 있음
https://daily-coorder.vercel.app/
[참고]
