인증과 인가

eunsiver·2023년 5월 25일

인증과 인가가 비슷하게 들릴 수도 있지만 IAM(Identity and Access Management) 환경에서는 명확히 구분되는 보안 프로세스입니다.

인증과 인가는 완전히 다른 개념이다.
둘 다 보안과 관련되었다는 점, JWT 토큰 기반인 경우 해당 토큰을 사용한다는 점에서는 동일하지만, 인증은 장치 혹은 사용자를 식별하는 행위이고 인가는 장치 및 사용자 엑세스 권한을 허용/거부하는 행위이다.

인증에 대한 정의

인증은 사용자의 신원을 검증하는 행위로서 보안 프로세스에서 첫 번째 단계입니다.

개념

인증은 '식별 내지는 신원 확인'이 목적이다. 즉, Server로 하여금 현재 request를 보내는 자가 누구인지를 식별할 수 있도록 만든 프로세스라는 의미이다. 따라서, 일반적으로 인증 프로세스는 아래의 절차를 따른다.

User가 입력한 자격증명 정보(ID, Password)를 Server로 전송 및 인증 요청(req)
Server는 요청과 함께 전달 받은 자격증명 정보를 토대로 Server와 연결된 User 관련 DB를 참조하여 request를 보내는 자가 누구인지 식별
결과적으로 인증 프로세스를 사용자 측에서 본다면, '로그인' 부분을 뜻한다고 이해해도 무방하다.

인증 요소(Factor)의 분류

최근에 인증 프로세스와 관련해서 SFA, 2FA, MFA 등의 기술이 등장하고 있는데, 이는 인증 요소의 분류와 관련된 개념이다.

지식 기반 요소 : 특정인이 알고 있는 정보 따위를 바탕으로 인증 (비밀번호 등)
소유 기반 요소: 특정인이 소유하고 있는 물건을 바탕으로 인증 (OTP, 휴대폰 인증, 공인인증서 등)
속성 기반 요소: 특정인의 고유 속성을 바탕으로 인증 (지문인식, 홍채인식 등)

위 요소의 나열 순서는 시간적 순서이다. 가장 원시적인 방법은 지식기반이었지만, 최근에는 소유기반을 넘어 속성기반으로의 인증이 점차 흔해지고 있다. 또한, 뒤에 등장한 방법일수록 보안성이 더 높다.

단일 기반의 요소만을 통해 인증이 이루어지는 경우를 SFA(Single Factor Authentication)
두 가지 기반의 요소를 통해 인증이 이루어지는 경우를 2FA(Two Factor Authentication)라고 부르며,
두 가지 이상의 기반 요소를 통해 인증이 이루어지는 경우를 MFA(Multi Factor Authentication)라고 부른다.

최근에는 비밀번호 없는 인증 기술의 논의가 활발하다.

인가 (권한 부여)에 대한 정의

시스템 보안에서 인가란, 사용자에게 특정 리소스나 기능에 액세스할 수 있는 권한을 부여하는 프로세스를 말합니다.

이 과정에서 '인증' 프로세스에서의 식별 결과를 활용하기도 하지만, 이는 어디까지나 권한의 차등적 부여를 위해 존재하는 것일뿐, 인가 프로세스의 필수요건은 아니다. 어떻게 만드느냐에 따라서, Server가 현재 request를 보내는 사람이 누구인지 전혀 모르더라도 권한을 부여하도록 만들 수도 있다.

일반적으로 권한 부여 프로세스는 아래의 절차를 따른다.
1. User의 접근 권한 요청(req)

2.요청과 함께 전달 받은 권한의 차등적 부여 관련 정보를 토대로 승인/거부

여기서 밑줄 친 '권한의 차등적 부여 관련 정보'와 관련해서 각종 Authorization 관련 기술들에 존재하는데, 대표적으로 Session에 특정 값을 넣어두고서 이를 체크하는 간단한 방식부터, JWT(JSON Web Token)이나 SAML(Security Assurance Markup Language), OAuth와 같은 기술들이 그것이다.

OAuth

웹 서핑을 하다 보면 Google과 Facebook 등의 외부 소셜 계정을 기반으로 간편히 회원가입 및 로그인할 수 있는 웹 어플리케이션을 쉽게 찾아볼 수 있다.

클릭 한 번으로 간편하게 로그인할 수 있을 뿐만 아니라,

연동되는 외부 웹 어플리케이션에서 Facebook 및 Twitter 등이 제공하는 기능을 간편하게 사용할 수 있다는 장점이 있다.

예를 들어, Google로 로그인하면 API를 통해 연동된 계정의 Google Calendar 정보를 가져와 사용자에게 보여줄 수 있다.

카카오 로그인, 네이버 로그인도 많이 사용되는데 연동된 계정의 사용자 정보 즉, 프로필 사진, 성별, 이름, 등등을 추가로 얻을 수 있다.

OAuth 탄생 배경

OAuth이 등장하기 전에 A 사이트에서 B 사이트의 리소스를 가져오기 위해서는 다른 사이트의 ID와 Password를 직접 입력 받아 저장하여 필요할 때마다 불러와서 사용을 해야했다. 위와 같은 방식을 사용하게되면 다음과 같은 문제가 발생한다.

사용자 : A 사이트에 B사이트의 ID와 Password를 넘겨주는 것에 대해 신뢰할 수 없다.
A 사이트 : ID와 Password를 받았기 때문에 보안 문제가 생기는 경우 모든 책임을 져야한다.
B 사이트 : A 사이트를 신뢰할 수 없다.

위와 같은 문제를 해결하기 위해 2006년 트위터 개발자와 Gnolia의 개발자가 안전한 인증방식에 대한 논의를 하면서 OAuth가 등장했고 2010년에 OAuth1.0이 발표되었다. 현재는 OAuth의 세션 고정 공격을 보완한 OAuth 1.0a를 거쳐, OAuth의 구조적인 문제점을 해결하고, 핵심요소만을 차용한 유사 프로토콜 WRAP(Web Resource Access Protocol)을 기반으로 발표한 OAuth 2.0가 많이 사용되고 있다.

OAuth 2.0(Open Authorization 2.0, OAuth2)

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.

구글, 페이스북, 카카오, 네이버 등에서 제공하는 간편 로그인 기능도 OAuth2 프로토콜 기반의 사용자 인증 기능을 제공

OAuth 2.0 주요 용어

직접 사용자가 로그인 하는것이 아닌, 소셜 미디어로 로그인을 할 경우,

client(개인 서비스)는 Resource Owner(사용자)를 대신해 로그인 하는데, 이때 필요한 정보를 Resource Server(kakao, naver, ...)에서 얻어 서로 비교해 유효성을 판단한다.

client가 유저의 (로그인)정보/자원(resource)을 Resource Server에 요청해 대신 로그인 하는 것이다.

이를 위해서 client는 다음 단계들을 가진다.

Resource Owner로 부터 동의(허용)
Resource Server로 부터 client 신원확인

Resource Owner(유저) 입장

자신의 정보를 대신 사용하기 때문에 client가 어떤 정보를 활용하는지, 어떤 기능을 사용하려는지 모른다.

나쁜 마음을 가지면 개인정보를 마구잡이로 악용할수 있을 수도 있기 때문이다.
그러므로 client는 Resource Owner의 동의를 구해야 한다.

Resource Server(kakao) 입장

다른 사람의 일을 대신 해주는 사람이 정말 그 사람일지 궁금할 수 있다.
마찬가지로 Resource Owner의 일을 수행 해주는 client가 정말 그 client일까 하는 물음이 있다.

이런 의미에서 Resource Server는 Resource Owner의 브라우저를 통해 client를 구분하는 값(code)를 전달한다.

기본으로 제공되는 것과 추가로 제공되는 부분이 있는데 사용자에게 얻고자 하는 정보를 선택하면 된다. 기본 정보는 자동으로 제공되고 추가 정보는 사용자에게 추가 동의를 받아야 한다.

Client ID, Client Secret , Authorized redirect URIs는 서비스를 등록하면 받게 되는 필수 요소로 특징은 다음과 같다.

Client ID

어플리케이션(서비스)을 식별하는 식별자ID를 의미한다.
다양한 서비스가 존재하는데, Resource Server 입장에서 어떤 서비스에게 제공할 것 인지 구분하는 ID를 의미한다.

Client Secret

Client ID에 대한 비밀번호로 외부에 노출되면 안된다.
ID의 PASSWORD라고 생각하면 된다.

Authorized redirect URIs

Resource Server만 갖는 정보로, client에 권한을 부여하는 과정에서 나중에 Authorized code를 전달하는 통로다.
나중에 client <-> Resource Server 유효성 검사에서 이 redirect URIs도 체크되며 해당주소가 아닐 경우 Resource Server는 해당 client가 아니라고 판단한다.
즉, 예를들어 네이버 서버가 사용자의 개인정보를 콜백할 주소를 적는 곳이다.

scope

Resource Server에서 사전에 사용 가능하도록 미리 정의한 기능
글 작성하기, ID알기, Email 알기, 캘린더 일정 입력하기 등등
페이스북이든 구글이든 로그인 되었다면, 그 서비스 안에서 사용할 수 있는 모든 기능

Resource owner 승인과정

사용자(Resource Owner)는 서비스(client)를 이용하기 위해 로그인 페이지에 접근한다.
그럼 서비스(client)는 사용자(Resource Owner)에게 로그인 페이지를 제공하게 된다. 로그인 페이지에서 사용자는 "페이스북/구글 으로 로그인" 버튼을 누른다.

만일 사용자가 Login with Facebook 버튼을 클릭하게 되면, 특정한 url 이 페이스북 서버쪽으로 보내지게 된다.

브라우저 응답(response) 헤더를 확인하면 다음 url내용을 확인 할 수 있다.

https://resource.server/?client_id=1&scope=B,C&redirect_uri=https://client/callback

이는, 사용자가 직접 페이스북으로 이동해서 로그인을 입력해야 하는데,

저 링크가 대신 로그인으로 이동 하게끔 도와준다.

https://resource.server/? # 리소스 서버(네이버, 카카오 사이트 url)
client_id=1 # 어떤 client인지를 id를 통해 Resouce Owner에게 알려주는 부분
&scope=B,C # Resource Owner가 사용하려는 기능, 달리 말해 client가 자신 서비스에서 사용하려는 Resource Server 기능을 표현한 부분
&redirect_uri=https://client/callback # 개발자 홈페이지에 서비스 개발자가 입력한 응답 콜백.

향후 redirect_uri 경로를 통해서 Resource Server는 client에게 임시비밀번호인 Authorization code를 제공한다.

클라이언트로부터 보낸 서비스 정보와, 리소스 로그인 서버에 등록된 서비스 정보를 비교한다.

4.1 확인이 완료되면, Resource Server로 부터 전용 로그인 페이지로 이동하여 사용자에게 보여준다.

ID/PW를 적어서 로그인을 하게되면, client가 사용하려는 기능(scope)에 대해 Resource Owner의 동의(승인)을 요청한다.

동의(Allow)를 누르는 것은 Resoure Owner는 Client가 해당 기능 사용에 위임(delegation)했다를 의미한다.

5.1 Resource Owner가 Allow 버튼을 누르면 Resource Owner가 권한을 위임했다는 승인이 Resource Server 에 전달된다.

이로써 Resource Sever가 갖는 정보는 다음과 같다.

Client Id : Resource Owner와 연결된 client가 누군지
Client Secret: Resource Owner와 연결된 client의 비밀번호
Redirect URL : (진짜)client와 통신할 통로
user id : client와 연결된 Resource Owner의 id
scope : client가 Resource Owner 대신에 사용할 기능들

하지만, 이미 Owner가 Client에게 권한 승인을 했더라도 아직 Server가 허락하지 않았다. 따라서, Resource Server 도 Client에게 권한 승인을 하기위해 Authorization code를 Redirect URL을 통해 사용자에게 응답하고
다시 사용자는 그대로 Client에게 다시 보낸다.

이를 통해, client는 Resource Server가 보낸 Authorization code, "code=3"를 Resource Owner통해 받는다.

이제 Client가 Resource Server에게 직접 url(클라이언드 아이디, 비번, 인증코드 ...등)을 보낸다.

그럼 Resource Server는 Client가 전달한 정보들을 비교해서 일치한다면, Access Token을 발급한다. 그리고 이제 필요없어진 Authorization code는 지운다.
그렇게 토큰을 받은 Client는 사용자에게 최종적으로 로그인이 완료되었다고 응답한다.

OAuth의 목적은 최종적으로 Access Token을 발급하는 것이다.

11 ~ 14. 이제 client는 Resource server의 api를 요청해 Resource Owner의 ID 혹은 프로필 정보를 사용할 수 있다.

Access Token이 기간이 만료되어 401에러가 나면, Refresh Token을 통해 Access Token을 재발급 한다.

Refresh Token

Refresh Token의 발급 여부와 방법 및 갱신 주기 등은 OAuth를 제공하는 Resource Server마다 상이하다.
Access Token은 만료 기간이 있으며, 만료된 Access Token으로 API를 요청하면 401 에러가 발생한다.
Access Token이 만료되어 재발급받을 때마다 서비스 이용자가 재 로그인하는 것은 다소 번거로울 것이다.

보통 Resource Server는 Access Token을 발급할 때 Refresh Token을 함께 발급한다.
Client는 두 Token을 모두 저장해두고, Resource Server의 API를 호출할 때는 Access Token을 사용한다.
Access Token이 만료되어 401 에러가 발생하면, Client는 보관 중이던 Refresh Token을 보내 새로운 Access Token을 발급받게 되어 로그인 인증을 유지 할 수 있게 된다.

참고

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC