✍️ HTTPS & SSL 에 대해
1. 양방향 암호화 - 비대칭 이란 무엇인가
비대칭키(공개키)방식은 암호화 복호화에 서로 다른 키를 사용
평문 - 암호화 + A키 → 암호문 (O)
암호문 - 복호화 + B키 → 평문 (O)
그럼 비대칭키는 어떻게 다른 키로 암호화 하거나 복호화 하는 걸까??
두개의 키는 수학적으로 밀접한 관계
다시 정리해보면, 비대칭형 암호화를 하면
하나의 키쌍이 생기고 이 두개의 키는 수학적으로 밀접한 관계를 가지고 있습니다.
두개의 키를 각각 키A, 키 B라고 했을 때
키 A로 암호화한 암호문은 키B로만 복호화 할 수 있습니다.
따라서 이 중 하나의 키는 공중에게 공개해도 상관 없고, (이를 '공개키'라고 부릅니다).
다른 하나의 키는 비밀로 보호합니다.(이를 '비밀키', '개인키'라고 부릅니다)
따라서 지금까지 공개해둔 A는 공개키(Public Key)로 사용된 것이고,
스판이만 가지고 있던 B 키는 비밀키(Private Key)로 사용된 것입니다.
이렇게 둘 중 하나의 키는 반드시 공개되어야 통상적인 사용이 가능함으로
비대칭형 암호를 공개키 암호라고도 부릅니다.
2. HTTPS 란 무엇인가?
프로토콜 : 어떤 방식으로 통신할 것인지에 대해서 정하는것. 통신규약
ex) 외국에 나가서 한 사람과 이야기를 꺼낼 때 어떤 언어로 할것인지
웹에서 사용하는 대표적인 통신 규약, 프로토콜이 바로 HTTP 입니다!
HTTP는 Hyper Text Transfer Protocol의 약자입니다.
인터넷에서 데이터를 주고받을 때는 이런이런 형식으로 데이터를 주고 받자!
라고 정해놨기 때문에 모든 웹프로그램들이 이 규칙에 맞춰 개발해서
서로 정보를 교환할 수 있게 된 것입니다.
구글 개발자 탭(F12)으로 보면, 어떤 식으로 HTTP 통신을 하고 있는지 알 수 있습니다!
3. 인증서란 무엇인가?
무조건 제공한 공개키로 쓰는것을 안심할 수 없다!
그 공개키가 Naver의 공개키인지, Never 의 공개키인지는
방문자 입장에서는 알 방법이 없기 때문에
신뢰할 수 있는 기관인 CA로부터
특정한 사이트가 사용한다는 내용을 담은 공개키를 이용하면,
해당 사이트가 맞음을 증명할 수 있게 됩니다!
이러한 추가적인 정보들이 있는 공개키를 바로 "인증서" 라고 부릅니다.
4. CA란 무엇인가?
인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 한다. 이 역할을 하는 민간기업들이 있는데 이런 기업들을 CA(Certificate authority)혹은 Root Certificate 라고 부른다.
CA는 아무 기업이나 할 수 있는 것이 아니고 신뢰성이 엄격하게 공인된 기업들만이 참여할 수 있다. 그 중에 대표적인 기업들은 아래와 같다.
Symantec
Comodo
GoDaddy
GlobalSign
✍️ JWT & OAuth 에 대해
1. Cookie & Session 이란 무엇인가
쿠키(Cookie) : 웹사이트에서 클라이언트에 저장해 놓는 데이터
클라이언트 A가 로그인 되었다는 정보를 남기기 위해서 A 가 로그인을 성공했을 때 유저의 id 가 15였다고 한다면,
user_id = 15 라는 값을 남겨 둡니다.
그리고 요청시마다 서버에서는 user_id = 15 값을 조회해서 id = 15 인 유저구나!
라는 식으로 인증을 할 수도 있습니다.
웹사이트를 방문할 때마다 읽히고 수시로 새로운 정보로 바뀔 수 있습니다.
페이지 탐색을 하거나 지역 및 언어, 성능에 대한 보고 혹은 마케팅 용 등 다양한 용도로 사용되곤 합니다.
이처럼 쿠키는 웹사이트 접속시 접속자의 개인장치에 다운로드 되고 브라우저에 저장되는 작은 텍스트 파일입니다. 웹사이트는 쿠키를 통해 접속자의 장치를 인식하고, 접속자의 설정과 과거 이용내역에 대한 일부 데이터를 저장합니다.
일반적으로 쿠키에는 만료일이 있습니다. 예를 들어, 브라우저를 닫는 경우 자동으로 삭제되는 쿠키도 있으며(세션 쿠키), 일부는 수동으로 삭제되기 전까지 남아있는 등 더 오랜기간 동안 컴퓨터에 저장되는 쿠키도 있습니다(지속적 쿠키).
세션(Session) : 현재 로그인 된 정보를 클라이언트의 쿠키가 아닌, 서버에 저장
서버가 무작위 값(Session Id)을 생성합니다. djsfkdjioj3n349v0
4. 서버가 무작위 값(Session Id)과 유저의 id 를 묶어서 세션 정보를 만듭니다.
5. 이제 그 Session Id 를 클라이언트에게 쿠키로 내려줍니다.
6. 클라이언트가 요청시마다 Session Id 를 같이 보내면, 서버에서 해당 Session 정보를 조회해서
"아, 현재 User(id=15) 가 로그인 한 상태구나!" 를 확인할 수 있습니다.
즉, session_id 는 추측하기 힘든 무작위의 해쉬값으로 생성한 뒤, 데이터베이스에 저장해둡니다.
이렇게 되면 다른 클라이언트에서 Session id 를 추측할 수 없을 뿐더러
해당 Session id 의 user_id 정보를 서버 측에서 보관할 수 있게 됩니다.
더욱 안전하게 관리할 수 있게 되는 것입니다!
2. JWT 란 무엇인가
Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token
이 때, 헤더와 내용은 JSON 형식이지만 이를 안전하게 전달하기 위해서
각각 base64 형태로 인코딩합니다.
인코딩 한 헤더와 내용을 특정 암호화 알고리즘을 통해서 암호화시켜 서명으로 사용합니다.
그렇게 되면 서명 부분을 복호화 했을 때의 값이 헤더 + 내용과 일치한다면
올바른 토큰이라는 것을 증명할 수 있습니다!
3. OAuth 에 있는 역할
-아이디와 비밀번호를 직접 넘겨주지 않고, 유저의 권한 중 넘겨주고 싶은 것만 설정해서 전달해주는 방법
-다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜
OAuth에서는 사진과같이 3자간의 관계가 핵심이된다.
Client - mine: 나의 서비스라고 이해하면 된다. 리소스 서버에 접속해 정보를 가져간다.
Resource Owner - User: 말그대로 서비스를 이용하는 사용자이다.
Resource Server - Their: 우리가 이용하고자 하는 리소스(자원)을 제공한다.
Authorization Server - 인증과 관련된 서버, resource server와 함께 묶을수 있다.
[출처] OAuth 1강. OAuth안의 역할|작성자 덩순이
4. OAuth 의 흐름에 대해 설명하기
- Resource Owner 가 Client 에게 소셜 로그인을 요청합니다.
- Client 의 정보(client_id, redirect_url)을 들고 Resource Server에게 갑니다.
- Resource Owner 가 자신의 계정정보를 이용해 Resource Server에 로그인합니다.
- Resource Server 에서 authorization_code 를 생성해 redirect_url 로 보냅니다.
- Resource Owner 는 redirect_url 에 도착해 Client 에게 authorization_code 를 보냅니다.
- Client 는 authorization_code 와 client_secret 을 이용해서 Resource Server 로부터
access_token 을 받아옵니다.- 이제 Client 는 access_token 을 가지고 Resource 에 자유롭게 접근이 가능합니다!
