여러 인증 방식이 있으므로 각 방식의 장단점을 파악하고 서비스 수준에 맞는 인증 방식을 선택해야 한다.
- API KEY 방식
    가장 기초적인 방법으로, 특정 사용자만 알 수 있는 문자열을 제공한다. 하지만 이 키가 노출되면 전체 API가 뚫리기 때문에 높은 보안인증이 필요할 경우에는 사용하면 안된다.
- API 토큰 방식
    사용자가 ID, 비밀번호로 인증하면 API 호출에 필요한 API 토큰을 발급 한다.
    설령 토큰이 탈취당하더라도 API만 호출할 수 있을 뿐 계정의 ID, 비밀번호는 알 수 없으므로 연쇄적인 피해를 막을 수 있다.
    API 토큰 방식에는 다양한 유형이 있어, 보안 수준에 따라 선택해서 사용할 수 있다.
    유형의 예로는 HTTP Basic Auth, Digest Access Authentication, 클라이언트 인증, 제3자 인증, IP화이트리스트, Bi-directional Certification 등이 있다.
- JWT 방식
    현재 많이 사용되는 방식인 JWT 방식은 Claim기반의 토큰 방식이다.
    Claim은 사용자의 속성을 뜻하며, 토큰에 이 내용이 들어 있으므로 별도로 사용자 정보를 호출할 필요가 없다.
    JWT는 변조 방지를 위해 다양한 알고리즘을 사용하여 복호화한 서명을 토큰 뒤에 붙인다.
    이렇듯 JWT 방식은 사용이 간단하지만 claim의 길이가 길어질수록 네트워크 부담이 커지고, 한번 토큰이 발급되면 수정, 폐기가 불가능하며 claim 정보는 암호화되지 않기 때문에 들어갈 정보를 잘 선별해야 한다는 문제점도 존재한다.

존재하는 사용자인지 인증이 되었다면 API 호출 권한이 있는 사용자인지 확인하는 과정이 필요하다.

- 인가 방식
    권한 인증 방식은 여러가지가 있지만, 가장 일반적인 방식은 RBAC(Role Based Access Control) 방식으로, 역할에 따라 권한을 갖게 되는 방식이다.
    한편 ACL(Access Control List) 방식은 역할 없이 사용자에게 직접 권한을 부여하는 방식이다.
- 인가 처리 위치
    인가 처리는 여러 계층에서 가능하지만 일반적으로 서버에서 처리하게 된다.
    API Gateway에서 인가에 필요한 필드를 변환해서 서버로 전달하면 구현을 간략하게 할 수 있다.
- 네트워크 레벨 암호화
    네트워크 레벨에서 가장 기본적인 보안 방법은 HTTPS 프로토콜을 사용하는 것이다.
    이것만으로도 메시지를 암호화해 전송하기 때문에 대부분의 메시지 누출은 막을 수 있다.
    하지만 중간자 공격을 통해 해커가 메시지를 가로챌 수도 있는데, 이를 막기 위해서는 공인 인증서를 사용했는지를 점검해야 한다.
- 메시지 본문 암호화
    메시지 전체가 아니라 필요한 필드만 애플리케이션 단에서 암호화할 수도 있다.
    그 경우 클라이언트와 서버가 암호화 키를 가지고 있어야 한다.
    암호화 키에는 대칭 키와 비대칭 키가 있는데, 이에 대해서는 예전 포스트에서 간단히 설명해 놓았다.
- 메시지 무결성 보장
    메시지가 변조되지 않았는지를 판단하기 위한 방법으로는 HMAC을 이용한 방법이 널리 사용되고 있다.
    클라이언트와 서버가 대칭키를 기반으로 한 암호화 키를 가지고, 호출 시 HMAC 알고리즘으로 키를 이용해 해시 값을 추출하여 메시지에 포함시킨다.
    만약 메시지가 변조될 경우 해시값이 달라지기 때문에 이를 통해 변조된 것을 알 수 있다.

- [https://velog.io/@jiffydev/%EB%8C%80%EC%9A%A9%EB%9F%89-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EC%99%80-%EC%84%B1%EB%8A%A5-%ED%8A%9C%EB%8B%9D-%EB%A0%88%ED%8D%BC%EB%9F%B0%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-1](대용량 아키텍쳐)

- [https://docs.aws.amazon.com/ko_kr/apigateway/](Amazon API Gateway)