인증 관련해서 서버의 부하를 줄일 수 있다.
마이크로 서비스로 전환 과정에서 필요함.
마이크로 서비스에서의 Session 사용은 지나치게 복잡하다.
서비스의 수평적 확장에 필요
여러 모듈에 대한 사용자들을 통합해서 관리 할 수 있다.
Access 토큰과 이를 발행하기 위한 Refresh 토큰을 사용한다.
암호화 알고리즘은 RSA256 을 사용한다.
비대칭 키를 사용해서 signature 를 generate 할 때와 validate 할 때 별도의 키를 사용한다.
public-key 는 인증 서버를 통해 발급 받을 수 있다.
key-size는 2045 이상의 크기를 사용한다.
여러 모듈(Micro Services) 들에 대한 사용자들의 정보를 가지고 있다.
SQL or NoSQL 데이터베이스 사용
필요시 Redis등의 Cache(인메모리 DB)를 사용 할 수 있다.
import jwt # !pip install PyJWT
prik = b"""-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAi/G11H74m8xI7AEnGjcxVUmM53q7rmSaUNmDhJ5/bRlkRZOM......
-----END RSA PRIVATE KEY-----"""
pubk = b"""-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAi/G11H74m8xI7AEnGjcx...
-----END PUBLIC KEY-----"""
if __name__ == "__main__":
encoded = jwt.encode({"this":"is", "test":"payload"}, prik, algorithm="RS256")
print(f"jwt: {encoded}")
decoded = jwt.decode(encoded, pubk, algorithms=["RS256"])
print(f"decoded: {decoded}")
print(f"{prik.decode()}")
print(f"{pubk.decode()}")
구조상 결정 사항
MSA 설계 방식에 알맞은 구조이다.
추후 확장성(scalability) 증가.
토큰의 발급과 인증을 한 서비스에서 관리 할 수 있다.
대칭키 사용 가능
인증 서버에 부하가 늘어난다.
API Gateway를 추가적으로 구현 해야 한다.
구조적으로 복잡도가 증가한다.
Validate한 토큰 이라면 권한을 확인 하고 그에 맞는 응답을 해준다.
Validate하지 않거나 새로운 토큰이 필요한 경우, 인증 서버로 Redirect 하거나(or) 토큰 발급을 요청한다.
구조적으로 구현이 단순하다.
IO의 횟수를 줄일 수 있어서 성능 면에서 유리하다.
토큰의 인증 관련해서 blacklist, whitelist 등의 방식을 사용하기 곤란하다.
코드 구현에 복잡도가 증가한다.
참고:
http://blog.eomdev.com/java/2016/05/30/API-Gateway.html
https://pyjwt.readthedocs.io/en/latest/usage.html
https://github.com/davedoesdev/python-jwt
Authentication & Authorization in Microservices Architecture
Authentication between microservices: Is it really that hard?