Authentication : A client must provide some evidence of who they are. This might involve signed certificates or it might involve credentials like a username and password. It might involve multiple factors, such as an sms message to a phone that the user should have access to. The web server must validate this authentication.
→ 특정 서비스의 서버는 사용자가 누구인지 식별할 수 있어야 한다.
Authorization : A server must define areas of authority and allocate these to groups of users. Furthermore, individual users must be defined as members of the authorization groups.
→ 클라이언트가 서비스에서 이용 가능한 기능의 범위. 권한에 대한 영역을 설정하고 각각의 사용자를 특정 권한 그룹에 포함시키는 것이 일반적.
인증 정보를 제공하는 다양한 방법이 있다.
1. 인증서: 암호화된 인증서로 디지털 서명 뿐만 아니라 인증 기관에 대한 참조를 포함한다. 이러한 인증서는 SSL(Secure Socket Layer)를 통해 교환된다. 일반적으론 서버 측에서 단방향으로 제공되는 정보이지만 특정 환경에서는 클라이언트와 서버가 모두 상호 인증에 사용되는 인증서를 갖고 있어야 하는 경우도 있다.
2. API 키 / 토큰: 웹 서비스는 특정 리소스에 접근 가능한 키를 제공할 수 있다. 키에 라이프-타임을 지정할 수도 있을 것이다.
3. 사용자 이름 / 비밀번호: 웹 서버는 사용자 이름과 비밀번호를 통해 사용자를 식별할 수 있다. e-mail, SMS 인증 단계가 추가될 수 있다.
4. 타사(Third-party) 인증: OpenID와 같은 서비스. 모든 사이트에 방문할 때마다 새로운 계정을 만들고 관리할 필요가 없다. 특정 사이트(Relying Party)는 OpenID Provider에게 인증을 위임하게 된다.
HTTP 인증
1. HTTP "Basic" 인증: 사용자 계정과 패스워드를 전송하는 방식. Base64 인코딩을 이용한다. 클라이언트 서버 간의 안전한 데이터 교환(암호화)을 위해 SSL(Secure Socket Layer)을 사용하며 각 요청에 Authorization 헤더가 포함된다.https://developer.mozilla.org/ko/docs/Web/HTTP/Authentication
2. HTTP "Digest" 인증: 클라이언트가 서버에 특정 페이지를 요청하면 서버는 Digest 인증이 필요하다고 통보하면서 nonce(자주 바뀌는 증표) 값 등의 서버 정보를 함께 전달한다. 클라이언트는 전달받은 nonce와 클라이언트 정보를 결합해 MD5(권장 알고리즘) 암호화하여 전송하고 서버는 이를 검증한다.
OpenSSL
OpenSSL은 Self-signed certificate를 만들 수 있는 툴이다. 프로덕션 레벨 전 단계에서 테스트 목적의 인증서를 발급하기 위해 주로 쓰인다. 프로덕션 레벨에서 쓰이는 공인 SSL 인증서의 경우엔 비용이 발생한다.(* SSL, 인증서: SSL은 웹 서버와 클라이언트(브라우저) 사이의 보안을 위한 프로토콜이다. SSL은 대칭키를 이용한 암호화 방식을 채택하고 있는데 이러한 암호화 통신(https)을 하기 위해선 SSL 인증서가 필요하다. 인증서에는 인증서 소유자의 정보, 용도, 유효기간, 공개 키 등의 정보가 포함되어 있다. 인증서가 유효한지는 CA가 보증해준다. 그리고 공인된 CA 목록은 이미 브라우저가 알고 있다.)
1. private key file을 만든다. 파일명은 ssl.key
→ openssl genrsa 1024 > ssl.key
2. [1]에서 생성한 key file을 가지고 certificate를 만든다. 파일명은 ssl.cert
→ openssl req -new -x509 -nodes -sha1 -days 365 -key ssl.key > ssl.cert
OAuth
OAuth는 인증을 위한 오픈 스탠더드 프로토콜. 버전 1.0, 1.0 A, 그리고 2.0 버전이 있는데 1.0 버전과 2.0 버전은 호환되지 않는다.OAuth에서 Auth는 Authentication 과정도 포함하지만 주 목적은 특정 기능에 접근하려는 사용자에게 해당 권한(Authorization)이 있는지를 확인하는 것이다. 그렇기 때문에 OAuth 인증을 진행할 때 해당 서비스 제공자는 '제3자가 어떤 정보나 서비스에 사용자의 권한으로 접근하려 하는데 허용하겠느냐'라는 안내 메시지를 보여주고 있다.
OAuth는 방문증을 수령하는 과정에 비유할 수 있다. 방문증은 사원증과 다르다. 예를 들면, 방문증을 가진 사람이 출입할 수 있는 곳은 제한적일 수 있다.
OAuth 1.0에 대한 개념 용어.
1. User: Service Provider에 계정을 가지고 있으면서, Consumer를 이용하려는 사용자.
2. Service Provider: OAuth를 사용하는 Open API를 제공하는 서비스 (Service Provider는 Open API를 제공함으로써 자연스러운 서비스 홍보 효과를 기대할 수 있다.)
3. Consumer: OAuth 인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스
4. Request Token: Consumer가 Service Provider에게 접근 권한을 인증받기 위해 사용하는 값. 인증이 완료된 후에는 Access Token으로 교환한다.
5. Access Token: 인증 후 Consumer가 Service Provider의 자원에 접근하기 위한 키를 포함한 값. (* 방문증 예시를 떠올리면 방문증이 Access Token 이다.)
OAuth 1.0 vs OAuth 2.0
1. OAuth 1.0은 웹 애플리케이션에 특화되어 있다면 OAuth 2.0은 다양한 형태의 애플리케이션에 대한 지원을 강화했다.
2. OAuth 2.0은 HTTPS를 사용하고 암호화 과정이 필요하지 않다.
3. OAuth 2.0은 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다.
이어지는 내용은 게으름으로. 링크만.
OAuth 2.0 정리글.
http://blog.weirdx.io/post/39955
토큰 기반 인증에 대한 정리글.
https://velopert.com/2350
https://velopert.com/2389
댓글 없음:
댓글 쓰기