인증/인가

인증/인가

인증(Authentication)

• 누구인가? (Login Id + Password)
• 누군가가 실제로 자신이 주장하는 사람임을 확인하는 과정
• 로그인이 인증 행위

인가(Authorization)

• 당신(you)이 무엇을 할 수 있나? (Permission)
• 누가 무엇을 할 수 있는지 결정하는 규칙을 의미
• 예) 철수는 데이터베이스를 만들고 삭제할 수 있는 권한이 있을 수 있지만 영희는 읽기 권한만 가지고 있다
• 주의) 철수와 영희가 누구인지는 밝히지 않는다 (인증 X) 단지 권한(Permission)만 체크

---

인증 방식

서버(세션) 기반 인증(Session-based authentication)

• 서버 측에 사용자의 정보를 기억/저장 - 세션을 유지한다
• 메모리나 디스크 또는 데이터베이스 등을 통해 관리한다
• 클라이언트로부터 요청을 받으면, 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스에 이용하는데, 이러한 서버를 Sateful 서버라고 한다
• 서버가 늘어나게 되면 세션 공유에 대해서 문제점이 발생한다
• 분산 처리 개발에 대한 요구사항이 필수로 생겨나게 된다
• CORS 에서 자유롭지 않다(cookie 에 등록된 도메인 한정)

 

토큰 기반 인증(Token-based authentication)

• 인증 할 때 토큰이라는 문자열을 만들어서 전달(토큰 발급)하고, 서버에 요청할 때 Http Header에 해당 토큰을 같이 보내는 과정
• 상태를 유지하지 않으므로 Stateless한 구조
• 토큰만 올바른 값이라면 인증 성공이기 때문에 손쉽게 시스템을 확장할 수 있다
• 무상태성(Stateless) & (시스템) 확장성(Scalability) & 보안성 (Security) & (토큰) 확장성 (Extensibility)
• CORS 에 대응 할 수 있고, 여러 플랫폼과 디바이스에도 대응이 편하다

 

API KEY

• 개요
  • 서비스들이 거대해짐에 따라 기능들을 분리하기 시작했는데 이를 위해 Module이나 Application들간의 공유와 독립성을 보장하기 위한 기능들이 등장하기 시작했다
  • 그 중 제일 먼저 등장하고 가장 널리 보편적으로 쓰이는 기술이 API Key
• 동작방식
  1. 사용자는 API Key 를 발급받는다 (발급 과정은 서비스마다 다르다)
  2. API를 사용하기 위해 Key와 함께 요청을 보낸다
  3. Application은 요청이 오면 Key를 통해 User 정보를 확인하여 누구의 Key인지 권한이 무엇인지 확인한다
  4. 해당 Key의 인증과 인가에 따라 데이터를 사용자에게 반환한다
• 문제점
  1. API Key 를 사용자에게 직접 발급하고 해당 Key를 통해 통신을 하기 때문에 통신구간이 암호화가 잘 되어 있더라도 Key가 유출될 경우에 대비하기 힘들다
  2. 그렇기 때문에 주기적으로 Key를 업데이트 해야하기 때문에 번거롭고, 예기치 못한 상황(한쪽만 업데이트가 되어 서로 매치가 안된다는 등)이 발생할 수 있다
  3. 또한, Key 한 가지로 정보를 제어하기 때문에 보안문제가 발생하기 쉬운 편인다

OAuth2

• 개요
  • API Key 의 단점을 보완하기 위해 등장한 방식
  • 대표적으로 페이스북, 트위터 등 SNS 로그인 기능에서 볼 수 있다
  • 요청하고 받는 단순한 방식이 아닌 인증하는 부분이 추가되어 독립적으로 세분화 되었다
• 동작방식
  1. 사용자가 Application의 기능을 사용하기 위한 요청을 보낸다 (로그인, 특정 정보 열람 등 다양한 곳에서 쓰일 수 있음)
  2. Application은 사용자가 로그인 되어있는지 확인한다 (로그인이 되어있지 않으면 인증서버로 Redirection)
  3. 간접적으로 Authorize 요청을 받은 인증서버는 해당 사용자가 회원인지 인증서버에 로그인 되어있는지 확인한다
  4. 인증을 거쳤으면 사용자가 최초의 요청에 대한 권한이 있는지 확인
  5. 이러한 과정을 Grant라고 하며 대체적으로 인증서버는 사용자의 의지를 확인하는 Grant 처리를 하게 되고, 각 Application은 다시 권한을 관리할 수 있다
  6. 사용자가 Grant 요청을 받게 되면 사용자는 해당 인증정보에 대한 허가를 내려준다 해당 요청을 통해 다시 인증서버에 인가 처리를 위해 요청을 보내게 된다
  7. 인증서버에서 인증과 인가에 대한 과정이 모두 완료되면 Application에 인가코드를 전달하고 인증서버는 해당 인가코드를 저장소에 저장해둔다 (인가코드 보안을 위해 짧은 기간동안만 유효하다)
  8. 인가코드는 짧은 기간만 유지되기 때문에 Application은 해당 인가코드를 Request Token으로 사용하여 인증서버에 요청을 보낸다
  9. Request Token을 받은 인증서버는 자신의 저장소에 저장한 코드와 일치하는지 확인하고 실제 리소스 접근에 사용하게 될 Access Token을 Application에게 전달한다
  10. Application은 Access Token을 통해 업무 처리를하고 Access Token을 통해 리소스 서버(인증서버가 아님)에 요청하게 된다 이 과정에서도 리소스 서버는 바로 데이터를 전달하는 것이 아닌 인증서버에 연결하여 Access Token이 유효한지 확인을 거치게 되며 Access Token이 유효하다면 요청한 정보를 받을 수 있다
  💡 Grant (인가와는 다른 개념) 인가는 서비스 제공자 입장에서 사용자의 권한을 확인하는 것이지만 Grant는 사용자가 자신의 인증정보(이름, 이메일 등)를 Application에 넘길지 말지를 결정하는 과정

 

• 문제점
  • 기존 API Key 방식에 비해 더 복잡한 구조를 가진다
  • 통신에 사용하는 Token은 무의미한 문자열을 가지고 기본적으로 정해진 규칙 없이 발행되기 때문에 증명확인이 필요하다
  • 인증서버에 어떤식이든(DBMS 접근, 다른 API 활용) 유효성 확인 작업이 필요하다는 공증 여부 문제가 있다
  • 유효기간 문제도 발생한다(유효기간이 짧은 인가코드, 유효기간이 긴 Request Token)

JWT(Json Web Token)

• 개요
  • 웹 표준(RFC 7519)로 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인 방식으로 정보를 안정성 있게 전달해주는, 인증 흐름의 규약이 아닌 Token 작성에 대한 규약
  • 기본적인 Access Token은 의미가 없는 문자열로 이루어져 Token의 진위나 유효성을 매번 확인해야 하는 것임에 반해 JWT는 인증여부 확인을 위한 값, 유효성 검증을 위한 값 그리고 인증 정보 자체를 담고 있기 때문에 인증서버에 묻지 않고도 사용할 수 있다
• 동작방식
  1. 사용자가 로그인(인증 토큰 생성)을 요청한다
  2. 사용자의 로그인 정보가 올바르면 Token을 생성하고 Token을 리턴한다
  3. 리턴받은 Token을 이용하여 Application에서 활용한다
• 문제점
  • 토큰 자체가 인증 정보를 가지고 있기 때문에 민감한 정보는 인증서버에 다시 접속하는 과정이 필요