본문으로 바로가기

TIL 2022-01-07 MySQL Case Sensitivity, OAuth, OAuth2.0

category TIL 2022. 1. 7. 23:52
MySQL Case Sensitivity

Lambda로 올린 Express 앱에서 데이터베이스 오류가 났다.

이유는 POSTS라는 데이터베이스가 없다는 것, 로컬에서는 잘 돌아갔는데, 무슨 문제인가 생각했었는데 Case Sensitivity 문제였다.

In MySQL, databases correspond to directories within the data directory. Each table within a database corresponds to at least one file within the database directory (and possibly more, depending on the storage engine). Triggers also correspond to files. Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database, table, and trigger names. This means such names are not case-sensitive in Windows, but are case-sensitive in most varieties of Unix.

윈도우에서는 Case-sensitive하지 않은 반면, Unix 기반의 운영체제에서는 case-sensitive하다고 한다!

내 RDS는 리눅스 OS 기반으로 돌아가고 있기 떄문에 Case-sensitive하기 때문에 이러한 문제가 발생했던 것이다.

 

 

 

OAuth

OAuth는 OpenID Authentication의 줄임말로, consumer와 service provider가 비밀번호를 공유하지 않고 authorization token을 사용해서 인증을 한다. 페이스북 계정을 통해 A라는 쇼핑몰에 접근할떄 A와 페이스북 비밀번호를 공유하지 않고도 페이스북 계정을 쇼핑몰에 사용할 수 있는 것이다. 만약 A가 보안적 이슈가 터졌어도 페이스북 비밀번호는 털리지 않는다.

 

OAuth는 메세지를 보낼떄 JSON을 사용한다.

 

OAuth는 정보에 대한 접근을 '허가'하는 개념이지 그 계정(사람)을 '인증'하는 개념이 아니다.

 

OAuth의 참가자는 User, Consumer, Service Provider로 나눌수 있는데,

 

User는 실 사용자

Service Provider는 페이스북, 트위터 같은 (유저)정보 제공자

Consumer는 Service Provider로부터 실사용자의 정보를 제공받을 소비자라고 할 수 있다.

단계로 보자면

1. User가 Consumer로 하여금 자신의 Service Provider의 정보에 접근하게 함.

2. Consumer가 Service Provider로부터 허가를 받음

3. User는 Service Provider로 리다이렉트

4. User는 Service Provider에게 Consumer의 정보 공유 허락함.

5. Consumer가 AccessToken을 받음

6. Consumer가 AccessToken으로 허가받은 리소스에 접근함.

 

OAuth 1.0 vs 2.0

 

OAuth 2.0은 1.0의 보안 문제들을 개선하여 나온 버전으로 1.0과 2.0은 호환되지 않으며

현재는 1.0을 지원하는 서비스는 다수 deprecated되었고 1.0 자체가 잘 쓰이지 않는다.

 

2.0의 장점들에 대해서 알아보자면

 

-Non-browser 앱들에 대한 지원이 나아졌다.

OAuth 기반의 (브라우저가 아닌) 앱들은 브라우저을 열어서 인증을 받고 토큰을 복사해 어플리케이션에 붙여넣어야하는 과정이 있었고, 사용자 경험면에서 꽝이었다.

-클라이언트 앱이 암호화 기능을 가질 필요가 없어짐

- signature가 훨씬 간단함

parsing, sorting, encoding 없음

- refreshToken을 사용해 accessToken의 수명이 짧도록 하여 보안성 늘림

- OAuth 요청을 하는 서버와 사용자 인증을 하는 서버의 역할을 분명히 구분함.

accessToken을 통해 접근하는 정보가 담긴 서버를 Resource Server, refreshToken과 accessToken에 관한 담당을 하는 Authorization Server

 

명칭도 다소 바뀌었다.

User -> Resource Owner

Service -> Resource Server

Consumer - > Client