User Management Theory 에 관해정리해보려 한다..
#사용자 인증(Authentication)과 권한 부여(Authorization)에 대한 이해
1. 사용자 인증(Authentication)과 권한 부여(Authorization)에 대한 이해
1-1 인증과 권한 부여의 차이 이해
사용자 인증 - 컴퓨터 보안에서 말하는 인증이란 어떤 실체가 그 실체가 맞는지 확인하는 것이다.
여기에는 4가지 유형이 있다.
- 지식 기반 인증(What you know)
• 고객이 알고있는 정보 기반으로 인증
• 비밀번호 등
• 유추가 가능하고 유출의 우려가 있음 - 소유 기반 인증(What you have)
• 고객이 소유하고 있는 것을 기반으로 인증
• 공인인증서, 시크리트 카드, OTP, 문자인증 등
• 지식 기반 인증과 함께 사용되면 강력함
• 복제/분실의 우려 존재 - 생체(존재) 기반 인증(What you are)
• 고객이 가지고 있는 고유한 생체적 특징을 기반으로 인증
• 지문인증, 홍체인증 등
• 분실이나 도난의 위험이 없고 복제가 어려움
• 재발급이나 변경이 안되므로 복제가 될 경우 위험
• 인증 실패(본인거부)의 가능성 - 행위 기반 인증(What you do)
• 주체가 하는 행위 기반으로 인증
• 걸음걸이, 서명, 음성 등
권한부여 - 인증에 성공한 사용자여도 부여된 권한 범위 내에서 애플리케이션 리소스에 접근할 수 있어야함을 의미한다. 즉, 사용자 인증을 거친 사용자라도 권한에 따라 제한이 될 수 있는것이다.
1-2 세션 기반 인증 : 쿠키와 서버 사이드 세션
사이트를 이용하다 보면 몇일이 지나도 로그인이 되어있거나, 몇분뒤 곧바로 세션이 만료되었다는 문구를 본적이 있을 것이다. 여기서 사용되는 개념이 쿠키 와 세션이기에 개념정리를 먼저 하겠다.
쿠키 - 쿠키란 서버가 사용자에게 보내는 작은 조각 개념이다. 서버에서 쿠키를 제공하면 이를 사용자 브라우저는 저장해놓았다가, 이후 서버에 재요청을 할때 데이터와 함께 보낸다. 서버는 이를 보고, 동일한 브라우저인지 아닌지 구분한다. 이를 이용하여 로그인 상태를 유지할 수 있다. 그러나 해킹의 위험이 있다.
세션 - 세션은 쿠키와 다르게 정보를 서버측에 저장하는 방식이다. 사용자 브라우저에서 요청시 sessionid를 생성하고 제공하면, 사용자는 데이터를 보낼때 마다, session id를 헤더에 추가하여 보낸다. 세션은 서버에 저장하기에 쿠키보다 비교적 안정적이다. 그러나 세션은 종료시 session id를 삭제 해버린다.
세션기반 인증 -
사용자가 인증을 할 때, 서버는 이러한 정보를 저장하고, 이를 세션(Session)이라고 부른다. 대부분의 경우에는 메모리에 저장하는데, 로그인 중인 사용자가 늘어날 경우에는 서버의 RAM에 부하가 걸리게 된다. 이를 피하기 위해 데이터베이스에 저장을 하기도 하는데, 이러한 방식 역시 데이터베이스에 무리를 줄 수 있다.
1-3 토큰 기반 인증 (JWT 사용 방법)
토큰인증 방식은 인증을 받은 사용자에게 토큰을 제공하고, 요청을 할때 토큰을 같이 보내도록 하여 유효성 검사를 하는 방식이다. 이렇게 한다면 서버측에서 관리하지 않아도 되기에 부담을 줄일 수 있다.
이러한 토큰은 클라이언트 측에 저장되기 때문에 서버는 완전히 Stateless하며, 클라이언트와 서버의 연결고리가 없기 때문에 확장하기에 매우 적합하다. 만약 사용자 정보가 서버 측 세션에 저장된 경우에 서버를 확장하여 분산처리 한다면, 해당 사용자는 처음 로그인 했었던 서버에만 요청을 받도록 설정을 해주어야 한다. 하지만 토큰을 사용한다면 어떠한 서버로 요청이 와도 상관이 없다.
1-4 Oauth: 외부 서비스를 이용한 인증 방법
직접 서버에서 인증과 관련된 로직을 처리할 필요 없이 인증을 중개하는 외부 서버를 이용한기술
- 권한 : OAuth는 인증뿐만 아니라 권한도 관리합니다. 사용자의 권한에 따라 접근할 수 있는 데이터가 다르도록 설정이 가능합니다.
- 프로토콜 : 특정한 프로그램을 지칭하는게 아니라 일종의 규격입니다. Facebook, Google, Naver 등은 OAuth라는 규격에 맞춰 인증 및 권한을 대행관리 해줍니다
- 외부서비스 : 우리가 만들고 있는 서비스를 이야기합니다. 외부 서비스를 위한 서비스인 OAuth는 우리 서비스의 인증 및 권한부여를 관리를 대행해줍니다.
Authorization Server: 권한을 관리하는 서버. Access Token과 Refresh Token을 발급 및 재발급해주는 역할
Resource Server: OAuth 2.0을 관리하는 서버(Google, Facebook, Kakao 등)의 자원을 관리하는 서버. 우리가 만드는 서버의 자원을 관리하는 곳이 아니라, OAuth 2.0 관리 서버의 자체 API를 의미한다.
과정
- Resource Owner(사용자)가 Client(우리 서버)에게 인증 요청을 한다.
- Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(Google 로그인, Facebook 로그인 URL)을 보낸다.
- Resource Owner는 해당 Request를 통해 인증을 진행하고, 인증을 완료했다는 신호로 Authorization Grant를 URL에 실어 Client에게 보낸다.
- Client는 해당 Authorization Grant(권한증서)를 Authorization Server에 보낸다.
- Authorization Server는 권한증서를 확인한 후, 유저가 맞다면 Client에게 Access Token, Refresh Token, 그리고 유저의 프로필 정보(id 포함) 등을 발급해준다.
- Client는 해당 Access Token을 DB에 저장하거나 Resource Owner에게 넘긴다.
- Resource Owner가 Resource Server에 자원이 필요하면, Client는 Access Token을 담아 Resource Server에 요청한다.
- Resource Server는 Access Token이 유효한지 확인한 후, Client에게 자원을 보낸다.
- 만일 Access Token이 만료됐거나 위조됐다면, Client는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급받는다.
- 그 후 다시 Resource Server에 자원을 요청한다.
- 만일 Refresh Token도 만료되었을 경우 Resource Owner는 새로운 Authorization Grant를 Client에게 넘겨야한다. (이는, 사용자가 다시 로그인을 해야된다는 뜻이다.)
장점 : 회원가입이라는 귀찮은 절차를 없애고, 사용자가 빠르게 회원가입을 할 수 있다.
접근하고 싶은 정보들은 사용자들이 미리 권한 내용을 확인하고 허락하기에 쉽게 접근할 수 있다.
