인증 방식 :: 기본 인증 원리부터 MSA 인증까지

인증 방식

 

1. API key를 통한 인증

과정

1. user가 login 정보를 입력한다.
2. Client는 이미 Server에 등록한 API key를 가지고 있다.
3. Client는 user가 입력한 Login 정보를 받아서 API key와 함께 Login API를 요청한다.
4. Server는 API key를 통해 해당 Client가 등록되어있는 지를 검사한다.
5. Sever는 Login 정보를 통해 해당 User가 API를 사용할 수 있는 지를 검사한다.

단점

• API key는 모든 Client들이 공통으로 사용하기 때문에 노출되면 전체 API가 노출된다.
• API key는 시간이 무제한이고 한 번 노출되면 API key 변경 전까지 계속 노출된다.

 

---

 

2. API Token을 통한 인증

 

과정

1. user가 login 정보를 입력한다.
2. Client는 입력된 login 정보와 함께 Login API를 요청한다.
3. API Server는 Auth Server에 인증을 요청한다.
4. Auth Server는 사용자를 인증하고, 인증되었는 지의 여부를 반환한다.
5. API Server는 인증된 User에게 API Token을 발급한다.
6. User는 이제 API Token을 가지고 있으므로 API 요청이 가능하다.
   1. 요청 시에 Cookie에 담아서 Request를 보낼 수 있다.
   2. Request Header에 직접 Authorization 속성으로 담아 보낼 수도 있다.

1번의 단계에서 보안을 강화하기 위해 Client ID, Client Serect을 함께 받는 방법(클라이언트 인증)을 추가로 사용할 수도 있고, OAuth 2.0를 사용하기도 한다.

https://hini7.tistory.com/209

OAuth 2.0

5번의 단계에서 API Token을 Access Token 하나만 발급할 수도 있고, 갱신을 위해 필요한 Refresh Token 까지 발급할 수도 있다.

https://hini7.tistory.com/211

Refresh Token

 

 

---

3. MSA 인증

 

지금까지는 monolitic architecture 에 대한 인증 방식이었다. API Token을 이용한 기존의 인증 방식 중 하나의 예를 살펴보고, MSA에서의 인증 방식을 살펴보자.

https://hini7.tistory.com/212

Micro Service Architecture이란?

 

기존의 인증 방식

 

기존의 API Token을 통한 인증을 간단히 나타내보면 위의 그림과 같다.

Client는 Login API를 통해 token을 얻어 저장하고 있으며, API 호출 시마다 저장된 Token을 사용하게 된다. 해당 token은 모든 서비스가 함께 이용한다.

위의 그림에서 credential을 true로 하여 request를 날리는 것은 Server가 response를 보내면서 token을 직접 넘겨주는 것이 아니라 Client의 쿠키에 접근하여 저장할 수 있게 하기 위해서이다.

 

MSA 인증 방식

MSA는 서비스가 각각 나뉘어져있기 때문에 SSO(Single Sign On)라는 인증 layer를 추가적으로 둬야 한다.

 

과정은 다음과 같다.

1. 각 서비스 Client에서 SSO에 login을 요청한다.
2. SSO는 login 정보를 가지고 Auth API에 인증을 요청한다.
3. Server는 인증된 User에게 Auth token을 발급한다.
4. Client는 발급받은 Auth token으로 Server에 직접 인증을 요청한다.
5. Server는 Auth token을 확인하고 API token을 발급한다.
6. Client는 발급받은 API token으로 API를 호출한다.