[CS-WEB]인증방식

지영·2023년 8월 29일

CS web 인증방식

CS

목록 보기

64/77

⛳ API KEY / OAuth / JWT 인증 방식에 대해 알아보겠습니다.

1. API KEY

REST API를 요청할 때, HTTP 헤더에 Authorization 정보를 추가하여 인증받을 수 있다. API를 요청한 계정의 소유자를 확인하는데 필수적인 절차이다.

서비스들이 거대해짐에 따라 기능들을 분리하기 시작하였는데, 모듈이나 애플리케이션들간의 공유와 독립성을 보장하기 위한 기능들이 필요해졌다. 가장 보편적으로 쓰이는 기술이 API Key이다.

동작방식

사용자는 API key를 발급받는다. (발급받는 과정은 서비스들마다 다르다.)
해당 API를 사용하기 위해 Key와 함께 요청을 보낸다.
애플리케이션은 요청이 오면 Key를 통해 유저의 정보를 확인하여 누구의 Key인지 권한 여부를 확인한다.
해당 Key의 인증과 인가에 따라 데이터를 사용자에게 반환한다.

사용

API Key같은 경우, 인증 외에도 다양하게 쓰이고 있다.

사용량 체크 (요금 부과)

유저의 API의 사용량을 체크 할 수 있으며, 유료API 서비스같은경우 사용량이 곧 요금이기 때문에 이를 체크할 수 있는 수단인 API Key가 필요하다.
사용량 제한(Rate Limit)
반대로 API 별 사용량을 제한 할 수 있다.
- DDoS 공격으로 부터 서비스를 보호한다.
- API 클라이언트 간에 API Resource의 사용에 공평성을 제공한다. 가령, 소수의 Heavy 클라이언트로 인해 다른 선량한 클라이언트가 피해를 입지 않도록 말이다.
- API를 통해 받는 데이터 자체가 돈과 직결되는 경우, 그 비즈니스 모델로서의 역할을 한다.

문제점

키 발급 시, 암호화가 잘 되어 있더라도 유출이 된다면 이를 해결하기가 쉽지 않다.
따라서, 주기적으로 키를 업데이트 해야하기 때문에 번거롭고 한쪽한 업데이트 되는 등 예외상황이 발생할 수 있다. 더불어 키만으로 정보를 암복호화하므로 보안문제 발생이 쉽다는 단점도 있다.

2. OAuth2

API KEY의 문제점을 해결하기 위한 기술이다. 대표적으로 페이스북, 트위터 등 SNS 로그인 기능에서 쉽게 볼 수 있다. 간편 로그인 기능에서 사용되는 방식으로, 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식입니다. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증을 사용됩니다.

동작방식

사용자가 애플리케이션의 기능을 사용하기 위한 요처을 보낸다. (예 : 로그인)
애플리케이션은 해당 사용자가 로그인이이 되어 있는지 확인한다. 로그인이 되어 있지 않으면 3단계로 넘어간다.
애플리케이션은 사용자를 인증서버로 Redirection한다.
간접적으로 인증요청을 받은 인증서버는 해당 사용자가 회원인지, 회원이라면 자신의 인증서버에 로그인이 되어있는지를 확인한다.
인증을 거쳤다면 사용자가 최초의 요청에 대한 권한이 있는지를 확인한다. 이러한 과정을 Grant라고 한다. 대부분의 인증서버는 Grant처리를 하게 되고, 각 애플리케이션은 다시 권한을 관리할 수 있게 된다. 이 과정에서 사용자의 Grant가 확인되지 않는다면 다시 사용자에게 Grant를 요청한다. (*Grant : 사용자가 자신의 인증정보(개인정보 등)를 애플리케이션에 넘길지 말지 결정하는 과정)
사용자가 Grant요청을 받게 되면 사용자는 해당 인증정보(개인정보 등)에 대한 접근 권한을 허가한다. 이를 통해 인증서버에 인가 처리를 위한 요청을 보낸다.
인증서버에서 인증과 인가 모두 완료되면, 애플리케이션에 인가코드를 전달한다. 인증서버는 해당 인가코드를 자신의 저장소에 저장을 해둔다. 해당 코드는 보안을 위해 매우 짧은 기간동안만 유효하다.
애플리케이션은 인증서버에서 받은 인가코드를 Request Token으로 사용하여 인증서버에 요청을 보내게 된다.
Request Token을 받은 인증서버는 자신의 저장소에 있는 인가코드와 비교하여, 일치한다면 긴 유효기간을 가진 실제 리소스 접근 권한을 주는 Access Token을 애플리케이션에게 전달한다.
Access Token을 받은 애플리케이션은 이제부터 업무를 처리할 수 있게 된다. 물론 이 Access Token이 유효한 기간동안만 사용자가 요청한 리소스를 전달할 수 있다.

문제점

Token은 무의미한 문자열을 가지고 기본적으로 정해진 규칙이 없으므로, 증명확인 필요하다. 따라서 유효성 확인 작업이 필요하다는 공증 여부 문제가 있다.
Token의 유효기간 여부 문제가 있다.

3. JWT(Json Web Token)

JWT는 인증 흐름 규약이 아닌, Token작성에 대한 규약이다. 기본적인 Access Token(위의 OAuth2같은..)은 의미없는 문자열로 이루어져 있어, 진위/유효성 여부 확인이 필수였다. 반면 JWT는 인증 여부 확인을 위한 값 / 유효성 검증을 위한 값 / 인증 정보 자체 로 이루어져있기 때문에 인증 서버에 묻지 않아도 사용이 가능하다.

동작방식

1. 사용자는 ID와 PW를 입력하고 서버로 요청을 보낸다.
2. 서버는 DB에서 회원을 조회하고 등록된 사용자인지 확인한다.
3. 등록된 사용자라면 서버는 토큰을 생성하고 JWT와 함께 사용자에게 응답한다.
4. 응답이 성공적이라면 로그인(인증)이 성공적으로 이루어진 것이고, 이후 요청에 Token을 함께 보낸다.
5. 서버가 로그인 이후의 요청과 함께 실려온 토큰을 검증하고 이를 성공적으로 끝냈다면 이때부터 권한이 있는 사용자라고 생각한다. 이제 사용자가 요청한 데이터를 받을 수 있게 된 것이다.