Digital identities
전자서명 방식들을 나열하고 비교한다.
Methods
1. OAuth2 - RFC 6749
- 2-legged(Resource owner password credentials grant, Client credentials grant: 보안 취약)
- 3-legged(Authorization code grant, Implicit grant)
- Authorization server에서 Access token을 저장하기도 한다.
- API 사용(리소스 서버에 요청) 시 기본적으로 매번 인증 서버에서 재검증받아야 한다.
- Reference:
> https://tools.ietf.org/html/rfc6749
2. JWT(JSON Web Token) - RFC 7519, 7523
- 헤더 및 내용에 서명을 붙여 Secret key로 암호화한 것을 토큰으로 사용
- OAuth에서 매번 Access token을 가지고 재요청하는 과정을 단순화시키기 위해,
access token 이외의 정보들도 JSON으로 표현하여 전달
- 클라이언트 쪽에 토큰 관리를 위임하여 서버의 부하를 줄일 수 있음
- Reference:
> https://tools.ietf.org/html/rfc7519
> https://tools.ietf.org/html/rfc7523
3. Self-sovereign
- Identity data를 개인의 기기에 저장하고 관리
- Claim(주장), Proof(자기증명, 여권 등), Attestation(기관증명) 세 단계로 서명
- Public key와 Private key를 이용한 Non-blockchain distributed ledger
- Reference:
> https://bitsonblocks.net/2017/05/17/a-gentle-introduction-to-self-sovereign-identity
> https://www.coindesk.com/path-self-sovereign-identity/
4. SAML(Security Assertion Markup Language) - RFC 7522
- Cross domain 간의 SSO(Single Sign On)
- A 사이트에서 로그인한 내역으로 B 사이트에서 추가 인증없이 서비스 이용 가능
- 사용자 편의성이 좋으나 간단한만큼 보안에 민감하지 않다.
- Reference:
> https://tools.ietf.org/html/rfc7522
> https://www.oasis-open.org/standards#samlv2.0
Conclusion
- OAuth2와 JWT를 동시에 사용하는 것이 서버의 부하를 줄이면서도 위변조 걱정을 덜 수 있다. 토큰에 개인정보 등의 민감한 정보를 담아 보내야 한다면, JWT는 사용하지말고 캐시 등을 이용하여 토큰의 내용을 서버에서 전적으로 관리해야 한다. SAML은 보안에 민감하지않고 간단한 서비스를 제공하는 서버에서나 적당해 보인다. Self-sovereign은 지금 시점에선 RFC도 없고 정립을 위한 토론이 필요한 단계라고 보인다. 새로운 형태의 인증 서버 구축이 필요하다면 컨셉을 차용할만 하다.
- 다양한 변수 및 공격이 있는 웹 환경에서는 인증 부분만 신경쓴다하여 모든 문제를 방지할 수 없다. Hole을 최대한 줄이기 위하여 어디에서든 암호화는 필수적으로 적용되어야 한다. 그것이 대칭이든 비대칭이든. (https://www.w3.org/TR/WebCryptoAPI/#multifactor-authentication)
Methods
1. OAuth2 - RFC 6749
- 2-legged(Resource owner password credentials grant, Client credentials grant: 보안 취약)
- 3-legged(Authorization code grant, Implicit grant)
- Authorization server에서 Access token을 저장하기도 한다.
- API 사용(리소스 서버에 요청) 시 기본적으로 매번 인증 서버에서 재검증받아야 한다.
- Reference:
> https://tools.ietf.org/html/rfc6749
- 헤더 및 내용에 서명을 붙여 Secret key로 암호화한 것을 토큰으로 사용
- OAuth에서 매번 Access token을 가지고 재요청하는 과정을 단순화시키기 위해,
access token 이외의 정보들도 JSON으로 표현하여 전달
- 클라이언트 쪽에 토큰 관리를 위임하여 서버의 부하를 줄일 수 있음
- Reference:
> https://tools.ietf.org/html/rfc7519
> https://tools.ietf.org/html/rfc7523
3. Self-sovereign
- Identity data를 개인의 기기에 저장하고 관리
- Claim(주장), Proof(자기증명, 여권 등), Attestation(기관증명) 세 단계로 서명
- Public key와 Private key를 이용한 Non-blockchain distributed ledger
> https://bitsonblocks.net/2017/05/17/a-gentle-introduction-to-self-sovereign-identity
> https://www.coindesk.com/path-self-sovereign-identity/
4. SAML(Security Assertion Markup Language) - RFC 7522
- Cross domain 간의 SSO(Single Sign On)
- A 사이트에서 로그인한 내역으로 B 사이트에서 추가 인증없이 서비스 이용 가능
- 사용자 편의성이 좋으나 간단한만큼 보안에 민감하지 않다.
- Reference:
> https://tools.ietf.org/html/rfc7522
> https://www.oasis-open.org/standards#samlv2.0
Conclusion
- OAuth2와 JWT를 동시에 사용하는 것이 서버의 부하를 줄이면서도 위변조 걱정을 덜 수 있다. 토큰에 개인정보 등의 민감한 정보를 담아 보내야 한다면, JWT는 사용하지말고 캐시 등을 이용하여 토큰의 내용을 서버에서 전적으로 관리해야 한다. SAML은 보안에 민감하지않고 간단한 서비스를 제공하는 서버에서나 적당해 보인다. Self-sovereign은 지금 시점에선 RFC도 없고 정립을 위한 토론이 필요한 단계라고 보인다. 새로운 형태의 인증 서버 구축이 필요하다면 컨셉을 차용할만 하다.
- 다양한 변수 및 공격이 있는 웹 환경에서는 인증 부분만 신경쓴다하여 모든 문제를 방지할 수 없다. Hole을 최대한 줄이기 위하여 어디에서든 암호화는 필수적으로 적용되어야 한다. 그것이 대칭이든 비대칭이든. (https://www.w3.org/TR/WebCryptoAPI/#multifactor-authentication)
댓글
댓글 쓰기