Web Security Service Model
Security Service Model은 다음과 같은 6가지로 분류 할 수 있다.1. Session-based security
2. HTTP Basic Authentication
3. Digest Authentication
4. Certificate Based security
5. XAuth
6. OAuth
1. Session Based Security
- 서버 사이드에서 사용자의 식별 정보를 세션에 저장하는 모델- 서버에서 보안이 필요한 리소스에 대한 요청을 받으면, 사용자 식별 정보를 세션에서 조회한다. 세션에 존재하는 경우 응답을 수행하지만, 그렇지 못한경우 로그인 요청한다.
A. 클라이언트가 보안이 걸린 리소스에 접근한다.
B. 보안 필터에서 해당 유저의 승인 정보가 세션에 존재하는지 검사한다.
C. 세션에 사용자 정보가 없음을 알린다.
D. 로그인 화면을 클라이인터에 노출한다.
E. 사용자 아이디/비번을 입력하고 인증 요청을 한다.
F. Authentication을 통해서 해당 유저가 적법한 유저인지 검사한다.
G. 적법한 유저인경우 승인정보를 세션에 저장한다.
H. Authorization을 통해 요청에 대한 허가를 한다.
I. 리소스에 접근한다.
J. 접근한 리소스를 클라이언트에 내려보내준다.
- Session Based Security는 매우 직관적이다.
- 그러나 최근 Stateless 서비스를 지원해주지 못한다.
- 상태정보를 세션에 저장해야하므로 Scale out 확장이 어렵다. (세션서버등 추가작업이 또 필요함)
2. HTTP Basic Authentication
- 사용자 인터렉션, 서버간의 인증 작업에서도 사용할 수 있다.- 보안된 리소스에 클라이언트가 접근하는 경우 서버는 401 "Unauthorized"응답 코드와 "WWW-Authenticate"헤더를 보낸다.
응답예)
- 보안된 리소스에 접근하면 다음과 같은 Header가 Client로 전송된다.
GET /resource
401 Unauthorized
WWW-Authenticate: Basic realm="SecurityResource"
- Basic : Basic Authenticate를 이용했다는 것을 의미한다.
- realm : 보안 대상이 되는 리소스 위치를 의미한다.
username과 password는 ":"를 구분자로 하여 Base64인코딩이 수행된다.
이렇게 인코딩이 된 정보는 서버로 전송이 된다.
GET /resource서버는 수신받은 credential 을 받으면 디코딩을 수행하고 검증한다.
Authorization: Basic hXY123HWKFKL34kdf
성공적으로 검증이 되면 리소스를 클라이언트로 전송한다.
A. 보안된 리소스를 요청한다.
B. 서버는 401을 반환하고 인증 정보를 요청한다.
C. 클라이언트는 username:password를 Base64인코딩하여 서버로 반환한다.
D. 서버는 Decode를 수행하고 적법한 사용자인지 검사한다.
E. 적법한 사용자인경우 보안된 리소스를 반환한다.
- 클라이언트가 인증정보를 매번 서버로 전송하기 때문에 stateless를 유지할 수 있다.
- 그러나 클라이언트는 단순히 encoding을 수행하는 것이지, 암호화 하는 것이 아니다.
- 즉, SSL/TLS 기반의 통신이 아닌경우라면 man-in-the-middle 공격에 매우 취약한 구조가 된다. (바로 username/password가 털릴수 있다. )
3. Digest Authentication
- Basic Authentication과 유사하다.- 서버는 401 상태코드를 클라이언트로 저장하고, 클라이언트는 서버로 WWW-Athenticate헤더에 Digest를 실어서 보낸다.
GET /resource서버에서 생성한 nonce와 qop를 이용하여 Digest 를 수행한다.
401 Unauthorized
WWW-Authenticate: Digest realm="SecurityResource", nonce="Xskldjfoqtj029sdlfj", qop="auth"
nonce는 암호화를 목적으로 하는 임의의 토큰이다.
qop는 "Quality Of Protection"으로 "auth"와 "auth-int"가 올수 있다.
- qop="auth" : digest는 authentication목적으로 사용된다는 것을 말한다.
> digest는 다음과 같이 생성된다.
hash_value_1 = MD5(username:realm:password)
hash_value_2 = MD5(request_method:request_url)
digest = MD5(hash_value_1:nonce:hash_value2)
- qop="auth-int" : 는 digest가 authentication목적으로 사용되고 integrity 요청을한다.
> digest는 다음과 같이 생성된다.
hash_value_1 = MD5(username:realm:password)
hash_value_2 = MD5(request_method:request_uri:MD5(request_body)
digest = MD5(hash_value_1:nonce:hash_value_2)
- 기본적으로 MD5알고리즘은 해시 값을 계산할때 사용된다.
- digest는 Authorization헤더를 서버로 전송된다.
- 요청을 받으면 서버는 digest를 계산하고, 사용자 정보를 검증한다.
A. 클라이언트가 보안된 리소스를 요청한다.
B. 서버는 401과 Digest 인증 요청을 한다. nonce와 qop를 클라이언트로 보냄
C. 클라이언트는 Digest 생성규칙에 따라 Digest생성한다.
D. Digest를 서버로 전송한다.
E. 서버에서 Digest를 검증한다.
F. 보안된 리소스를 반환한다.
- Basic Authentication보다 더 보안에 강하다.
- SSL/TLS상에서 커뮤니케이션 하지 않는경우 여전히 중간에서 Digest를 탈취하여 재현할 수 있다.
- 서버에서 생성된 nonce와 qop는 1회성이다. 즉 매번 Digest를 생성하고 검증해야함을 의미한다.
- 단방향 알고리즘을 이용할때 bcrypt등을 이용하여 더욱 보안을 강화할 수 있다.
4. Certificate-Based Security
- Certificate-Based Security는 Certificate를 필요로 하는 보안이다. 이는 파티의 식별을 수행하는 방식으로 수행된다.- SSL/TLS 기반의 커뮤니케이션에서 클라이언트는 브라우저 등에서 서버의 인증을 인증서를 검증한다. 이 모델은 상호 인증을 수행하면서 길어질 수 있다. 서버는 클라이언트 인증을 SSL/TLS핸드쉐이크 과정에서 요청할 수 있고, 이를 통해 클라이언트를 식별할 수 있다.
- 이 접근 방법은 보호된 자원 요청을 수신받으면 서버는 클라이언트로 인증 정보를 보낸다. 클라이언트는 서버가 신뢰된 Certificate Authority(CA)이라는 것을 확인하고, 인증서를 서버로 보내게 된다.
- 서버는 클라이언트의 인증서를 검증하고 적법한경우 보호된 자원을 반환한다.
- Certificate-Base security 모델은 보안정보를 전송하지 않고 제거한다. 이는 username/password 모델보다 더욱 보안에 강하다.
- 그러나 인증서 배포와 관리비용이 높을 수 있어 보통 큰 시스템에 이용한다.
5. XAuth
- 사용자의 이름과 비밀번호를 저장하지 않고 보안을 제공해준다.- 클라이언트에서 사용자 이름과 비번을 서버로 전송하면, 서버에서는 해당 정보를 검증하고 토큰을 발행하여 클라이언트로 내려보내준다.
- 클라이언트는 수신받은 토큰정보를 저장하고, 이름과 비밀번호를 파기한다.
- 클라이언트가 이후 보안된 자원을 요청하게 되면 토큰을 전송한다. 이는 X-Auth-Token 헤더와 같은 곳에 실어서 전송하게 된다.
- 토큰의 수명은 서비스에 의해 결정이 된다. 토큰은 그것이 expire되기전까지 다양한 요청을 revoke할 수 있다.
A. 사용자가 필요한 인터넷 접근을 수행하기 위해서 클라이언트 접속
B. 클라이언트에서 Credential을 사용자에게 요청
C. 사용자는 username/password를 클라이언트로 전송
D. 클라이언트는 서버로 Username/Password를 다시 전송
E. 서버는 검증을 통해서 AccessToken을 발행하여 클라이언트로 전송
F. Access Token을 저장하고 보안된 자원에 접근이 필요한경우 AccessToken을 전송함
G. 서버는 유효기간 내의 AccessToken인경우 보안된 자원을 반환함
- 동일한 조직에서 상호간 통신을 할때 매우 유용한 모델이다.
6. OAuth 2.0
- Open Authorization 혹은 OAuth는 보호된 자원에 접근하기 위해서 사용자의 패스워드를 저장하는 대신 사용하는 프레임 워크이다.- OAuth 2.0에서 규정하는 역할
1. Resource Owner : resource owner는 그들의 어카운트나 자원에 접근하기를 원하는 개체이다.
2. Client : 사용자의 자원에 접근하는 어플리케이션이다.
3. Authorization Server : 사용자의 실별정보를 검증하고 사용자 리소스에 접근하기 위한 토큰을 생성한다.
4. Resource Server : 보호된 사용자의 리소스 가지고 있는 서버이다.
- SSL기반위에서 상기 역할들 상호간에 통신이 이루어 진다.
- OAuth를 이용하기 전에 사전에 사용자가 Authorization Server에 정보가 등록 되어 있어야 한다.
A. 사용자가 클라이언트에 서비스를 이용하기 위해 접근한다.
B. 클라이언트는 사용자에게 인증 요청을 하라고 한다.
C. 사용자는 인도된 Authorization서버에 접속하여 인증 과정을 거친다.
D. 적법한 사용자인경우 인증 완료되었음을 Client에 알려준다.
E. Client는 어플리케이션 이용을 위한 Access Token을 인증서버에 요청한다.
F. 인증 서버는 Access Token을 발급한다.
G. Access Token으로 사용자가 접근하고자 하는 자원에 접근한다.
H. 유효한 Access Token인경우 보안된 리소스를 반환한다.
- OAuth2의 장점은 다양한 클라이언트를 수용한다는 것이다. 웹 어플리케이션, 네이티브 어플리케이션, User Agent/Browser어플리케이션등 다양한 곳에 이용될 수 있다.
- Access Token이 발급되면 이후 인터렉션은 Access Token으로만 수행한다. 즉, 사용자의 이름/비밀번호가 공유되지 않는다.
- Access Token은 만료 기간까지 사용할 수 있으며, 만료된 경우 Refresh Token을 이용하여 Access Token을 갱신할 수 있다.
참고 Link :
http://foorious.com/webdev/auth/oauth2/
http://code.pearson.com/pearson-learningstudio/apis/authentication/authentication-concepts/concept-oauth-2_x
EmoticonEmoticon