TIL 21.06.29

Jaemin Jung·2021년 7월 3일

Today I Learned

목록 보기

49/62

오늘한일

오늘은 어제보다는 숨통이 트였다
나는 쌩판 처음보는 개념에 대해서 두려움이 있나보다.
항상 그래왔다.
처음 개념을 배울때와 이 개념의 존재를 알게된 뒤 부터는
뇌의 회전속도가 항상 달랐다
처음 개념을 배울때는 정말 쉬운 문제 해결도 잘 못할때가 많다
약간 시야가 좁아지는?
이점을 고쳐나가야겠다

Achievement goals

세션 및 쿠키 / 토큰 / OAuth를 통해 인증 구현을 할 수 있다.
클라이언트, 서버, 데이터베이스의 전체 동작을 이해할 수 있다.
회원가입 및 로그인 등의 유저 인증에 대해 구현하고 이해한다.
서비스의 보안과 관련된 방법을 알아보고 원리 및 장점 및 단점을 이해한다.

Token

세션기반 인증은 서버에 유저 정보를 저장하는 인증 방식이었다.
하지만 세션은 서버에 정보를 저장하기 때문에 서버의 성능이 낮아질 우려가 있고,
매 요청마다 서버나 데이터베이스를 조회해야한다. 그리고
하나의 서버에서만 사용이 가능했기에 여러 서버를 가진 서비스에게 세션은 비효율적인 인증 방식이다.

이러한 한계점을 보완한 다른 인증 방식인 토큰이 있다.
일상생활에서 토큰은 입장티켓과 같은 역할을 한다.

오락실 게임에 사용하는 토큰
행사에 입장하기 위해서 주최측에서 나누어 준 토큰
놀이공원에 입장료를 내면 주는 토큰

보안에서도 마찬가지다.
클라이언트에서 토큰을 가지고 있다면 해당 토큰이 없는 유저들과는 다르게
서버에서 제공하는 다양한 기능을 요청할 수 있다.
그렇다면 토큰은 굉장한 힘을 가진 정보인것이다.

JSON Web Token (JWT)

앞서 쿠키의 한계점인 민감한 정보는 클라이언트에 저장하면 안된다고 했는데
토큰은 유저 정보를 암호화한 상태로 담을 수 있고, 암호화 했기 때문에 클라이언트에 담을 수 있다고 한다.

클라이언트에서 자신의 데이터를 볼 수 있는데 수정은 하지 못하게 하는것이다.
그 데이터를 수정을 하려고 하면, 무조건 서버를 통해서만 가능하게 하는것이다.
이 것을 가능하게 하는것이 jwt다.

jwt의 구조

jwt의 구조는 세마디로 이루어져있고 각각 JSON 형태로 정보를 표시한다.
JSON 형태인 각 부분은 Base64로 인코딩 되어 표현된다.

Header: 어떤 타입의 데이터를 다룰지, 암호화, 해싱 알고리즘에 대한 정보를 담는다.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload: 실제 보관할 데이터를 담는다. 민감한 정보는 되도록 담지 않는 것이 좋다.

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

Signature: Header와 Payload를 조합하고 비밀키(암호화에 추가할 salt)를 이용해서 해시 값을 만들어냄,
서버는 유저가 보내준 Header와 Payload를 이용해서 직접 Signature를 만들고,
기존에 보내주었던 Signature값과 비교를 하고,
값이 다르다면 무언가 조작된 데이터임을알아차릴수 있다.
비밀키는 서버에서만 보관을 해야하고 클라이언트가 절대로 알면 안되는 값이다.

HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

OAuth 2.0

OAuth2.0은 보안 된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공(Authorization)하는 프로세스를 단순화하는 프로토콜 중 한 방법이다.

예를 들어서 웹이나 앱에서 소셜 로그인 인증 방식은 요즘 흔히 볼 수 있다.

네이버 로그인, 카카오 로그인 기능을 구현할때 간단한 방법은
사용자의 네이버 아이디/비밀번호를 받아서 로그인을 해주면 된다.
이 방법은 말도 안되는 방법이다.
사용자에게는 제 3의 서비스가 본인의 네이버 아이디 비밀번호를 가지고 있는다는것은 매우 위험한 일이기 때문이다.
그렇다면 어떻게 이를 구현해야할까? OAuth 2.0은 다른 서비스의 데이터를 사용하도록 허락을 받는 과정이라고 설명하면 될거같다. 다른말로 다른 서비스의 회원 정보를 안전하기 사용하기 위한 방법이 더 적절할거 같다.

용어

Resource server : 자원을 가지고 있는 서버 (네이버, 카카오)
Authorization server : 인증과 관련된 처리를 전담하는 서버
Resource Owner : 리소스 서버에 자원을 가지고 있는 사용자
Client: Resource owner를 대신하여 보호된 리소스에 액세스하는 응용프로그램

소셜 로그인 로직 플로우

앞서 소셜 로그인 인증 방식에서 아이디/비밀번호를 받지 않고 어떻게 데이터를 받아올 수 있냐면,
OAuth 2.0는 엑세스 토큰을 활용한다.
사용자의 요청으로 인해 연동하려는 서비스(네이버)에 우리의 서비스는 네이버에 엑세스 토큰을 발급받고
그 엑세스 토큰을 통해서 데이터를 가져올 수 있게 한다.