💡인증 VS 인가

인증(Authentication)

인증은 어떤 사실 또는 어떤 문서가 진짜인지 증명하는 과정을 가리키는 용어입니다.
일반적으로 컴퓨터 과학 분야에서는 사용자의 신원을 증명하는 것과 관련이 있습니다.
사용자는 사용자와 시스템간에 공유되는 합의된 정보를 제공하여 자신의 신원을 증명합니다.

여러 웹 서비스들은 회원이어야 만이 이용할 수 있는 경우가 많다.
회원이 아닐 경우에는 해당 서비스를 이용하기 위해서는 회원 가입을 통해 아이디와 패스워드를 만들고, 회원 가입하려는 사용자가 본인이 맞는지 확인하는 절차를 가지게 된다.

회원일 경우에는 로그인을 함으로 회원이 맞음을 인증해야 한다. 아이디와 패스워드를 입력하여 아이디에 해당하는 패스워드가 일치할 경우에만 인증 절차에 성공하여 서비스를 이용할 수 있게 된다.

인가(Authorization)

인증과 달리 권한 부여는 엔터티(사용자 또는 장치)가 액세스 할 수 있는 리소스 또는 수행할 수 있는 작업,
즉 액세스 권한을 확인하는 프로세스를 의미합니다.

상품을 판매 또는 구매를 할 수 있는 인터넷 쇼핑몰이 있다고 가정한다.
고객은 해당 쇼핑몰에서 상품을 구매할 수 있는 권한을 부여받은 것이며, 판매자는 상품을 등록하고 판매할 수 있는 권한을 부여받은 것이다.

해당 쇼핑몰에서는 여러 가지 형태로 인가를 할 수 있다.

• 모든 회원이 상품 구매와 판매를 동시에 진행할 수 있도록 모든 권한을 부여한다.
• 회원을 구매자와 판매자로 구분하여 구매자는 구매만 할 수 있고, 판매자는 판매만 할 수 있도록 권한을 부여한다.
• 모든 회원은 구매를 할 수 있으나, 판매자는 신청을 통해 통과된 사용자만 판매자 권한을 부여받을 수 있도록 한다.

💡OAuth

OAuth란?

구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization) 받을 수 있는 표준 프로토콜이다.
쉽게 말하자면, 우리의 서비스가 우리 서비스를 이용하는 유저의 타사 플랫폼 정보에 접근하기 위해서 권한을 타사 플랫폼으로부터 위임 받는 것 이다.

• OAuth의 주된 목적은 사용자의 자격 증명을 제3의 애플리케이션에 제공하지 않고도, 제3의 애플리케이션이 사용자의 자원(예: 이메일, 연락처 목록 등)에 접근할 수 있도록 권한을 부여하는 것이므로 인가(Authorization)에 해당합니다.

등장배경

• 필요성

  우리의 서비스가 사용자를 대신하여 구글의 캘린더에 일정을 추가하거나, 페이스북, 트위터에 글을 남기는 기능을 만들 수 있을 것 이다. 이때, 가장 쉽게 이 기능을 구현하는 방법은 사용자로부터 구글, 페이스북, 트위터의 ID, Password 를 직접 제공받아 우리의 서비스에 저장하고 활용하는 방법이다.

• 제한사항

  우리 입장에서는 사용자의 아주 민감한 정보를 직접 저장하고 관리해야한다는 부담이 생길 것 이다. 또한 구글, 페이스북, 트위터는 자신의 사용자 정보를 신뢰할 수 없는 제3자에게 맡긴다는 것이 매우 불만족스러울 것 이다.

• 과거 해결책

  OAuth 가 등장하기 이전에는 구글은 AuthSub, 야후는 BBAuth 등 각자 회사가 개발한 방법을 사용하였다. 하지만 이 방식은 표준화 되어있지 않기 때문에 구글과 연동하는 서비스를 만들기 위해서는 AuthSub, 야후와 연동하기 위해서는 BBAuth 에 맞춰 개별적으로 개발하고 유지보수 해야한다.

• OAuth의 등장

  최초 1.0 버전은 2006년 트위터와 Ma.gnolia 가 주도적으로 개발하였다. 이후 1.0버전이 개선된 1.0a 버전이 출시되었으나 모바일 어플리케이션 등에서 안전하게 사용될 수 없는 사례가 존재했다. 이런 사례를 보완하고 기존 버전보다 조금 더 단순화한 OAuth 2.0 버전이 2012년에 등장하게 되었다.

OAuth 2.0의 주체

• Resouce Owner

  리소스 소유자. 우리의 서비스를 이용하면서, 구글, 페이스북 등의 플랫폼에서 리소스를 소유하고 있는 사용자이다. 리소스라 하면 '구글 캘린더 정보', '페이스북 친구 목록', '네이버 블로그 포스트 작성' 등이 해당될 것이다.

• Authorization & Resource Server

  Authorization Server는 Resource Owner를 인증하고, Client에게 액세스 토큰을 발급해주는 서버이다. Resource Server는 구글, 페이스북, 트위터와 같이 리소스를 가지고 있는 서버를 말한다.
  Authorization Server와 Resource Server는 공식문서상 별개로 구분되어 있지만, 별개의 서버로 구성할지, 하나의 서버로 구성할지는 개발자가 선택하기 나름이라고 한다.

• Client

  Resource Server의 자원을 이용하고자 하는 서비스. 보통 우리가 개발하려는 서비스가 될 것이다.
  Client는 우리가 구현하는 서비스이므로 Resource Owner와 헷갈리지 말자. Resource Server와 Authorization Server의 입장에서는 우리 서비스가 클라이언트이기 때문에 이런 이름을 갖게 된 것이다.

OAuth 2.0의 동작 메커니즘

💡JWT

JWT란?

JWT(Json Web Token)은 웹 표준에 따른 데이터 전송을 위한 간결한 방법으로, 주로 사용자 인증과 정보 교환에 사용됩니다. JWT는 헤더, 페이로드, 서명 세 부분으로 구성되어 있으며 각 부분은 마침표로 구분됩니다.

• Header(헤더): 토큰의 타입과 해싱 알고리즘을 포함합니다. 예를 들어, {"alg": "HS256", "typ": "JWT"} 같은 형태로 구성됩니다.

{
  "alg": "HS256",
  "typ": "JWT"
}

• Payload(페이로드): 토큰에 포함될 실제 데이터가 들어있습니다. 이 데이터는 클레임(claim)이라고도 하며, 사용자 정보, 만료 시간, 발급자 등 다양한 정보를 담을 수 있습니다. 이 부분은 Base64로 인코딩되기 때문에 누구나 디코딩할 수 있지만, 디지털 서명을 통해 위조 방지 기능이 추가됩니다.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

• Signature(서명): 토큰의 무결성을 확인하기 위해 사용됩니다. 헤더와 페이로드를 조합하여 비밀 키를 사용해 해싱한 값입니다. 서명을 통해 토큰이 발급 이후 변경되지 않았음을 보장할 수 있습니다.
  signature는 서버에 있는 개인키로만 암호화를 풀 수 있으므로 다른 클라이언트는 임의로 Signature를 복호화할 수 없습니다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
)

인증방식

1. Browser(사용자)가 로그인을 한다.
2. 서버는 사용자가 로그인에 성공하면 User ID 등을 Secret Key로 생성한다.
3. 서버는 만들어진 JWT를 사용자에게 반환한다.
4. 사용자는 인가를 필요로 하는 요청 Authorization Header에 Token을 넣어 요청한다.
5. 서버는 Token을 기반으로 사용자의 정보를 가져온다.
6. 서버는 Token으로 가져온 사용자의 정보를 기반하여 응답을 해준다.

Siganature은 어떻게 만들어지나요?

1. 헤더와 페이로드 인코딩

• JWT의 헤더와 페이로드를 각각 Base64 URL 인코딩합니다.

2. 서명 생성

• 서명은 보통 HMAC SHA256 알고리즘을 사용해 생성됩니다.
• 서명은 인코딩된 헤더와 페이로드를 조합한 문자열을 비밀 키와 함께 해싱하여 생성합니다.

서명 과정은 다음과 같이 표현됩니다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
)

3. 서명 추가

• 생성된 서명은 JWT의 마지막 부분에 추가됩니다.

4. 서명 예시

• 헤더

{
  "alg": "HS256",
  "typ": "JWT"
}

• 페이로드

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

1. Base64 URL 인코딩된 헤더

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

2. Base64 URL 인코딩된 페이로드

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

3. 서명

• 비밀 키를 "your-256-bit-secret"라고 가정할 때, 서명은 아래와 같이 생성됩니다.

HMACSHA256(
  "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9",
  "your-256-bit-secret"
)

• 서명을 계산하면 다음과 같이 나옵니다.
  SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
• 최종 JWT는 다음과 같이 구성됩니다.
  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

이 JWT를 서버로부터 받는 클라이언트는 요청을 보낼 때 이 JWT를 사용하고, 서버는 비밀 키를 사용해 서명을 검증하여 토큰이 변조되지 않았는지 확인할 수 있습니다.

Access Token이 탈취된다면?

Access Token은 발급된 이후, 서버에 저장되지 않고 토큰 자체로 검증을 하며 사용자 권한을 인증하기 떄문에, Access Token이 탈취되면 토큰이 만료되기 전 까지, 토큰을 획득한 사람은 누구나 권한 접근이 가능해진다. JWT는 발급한 후 삭제가 불가능하기 때문에, 접근에 관여하는 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대해 대응을 하여야 한다.

1. Access Token의 만료 시간 짧게 설정

• 액세스 토큰의 유효 기간을 짧게 설정하면, 탈취된 토큰의 사용 가능 기간을 줄일 수 있습니다. 예를 들어, 5분 또는 10분과 같은 짧은 만료 시간을 설정할 수 있습니다.
• 유효 기간이 짧은 대신, 리프레시 토큰을 사용하여 만료된 토큰을 갱신하는 방법을 사용할 수 있습니다.

2. 토큰을 무효화하는 방법

• 블랙리스트 : 특정 토큰을 서버에서 블랙리스트에 추가하여 해당 토큰을 무효화할 수 있습니다. 서버는 블랙리스트를 확인하여 탈취된 토큰을 거부할 수 있습니다.
• Invalidation API : 클라이언트에서 로그아웃 시나, 의심스러운 활동이 발견된 경우 토큰을 무효화할 수 있는 API를 제공하여 사용자가 직접 토큰을 폐기할 수 있게 합니다.

Refesh Token이 탈취된다면?

• Refresh Token Rotation(RTR)

  Refresh Token을 One time Use Only로 설정한다. (한번 쓰면 다음 refresh token을 발급)

• 한번 이상의 Refresh Token 의 사용이 감지되면, 탈취된 것으로 간주하고 탈취된 것으로 간주 된 Refresh Token으로 인해 발급된 모든 Refresh Token 들을 폐기한다.
  

• 하지만 해커가 지속적으로 Access Token 만 탈취한다면, 무용지물이 된다.
  

💡OAuth VS JWT

JWT는 토큰의 종류이고, OAuth는 토큰을 발급하고 인증하는 오픈 스탠다드 프로토콜이다.

• JWT는 헤더(Header), 페이로드(Payload), 서명(Signature) 세 부분으로 구성됩니다. 헤더에는 토큰 유형과 암호화 알고리즘 정보가 포함되어 있으며, 페이로드에는 클레임(Claim) 정보가 포함됩니다. 클레임은 사용자, 권한, 유효 기간 등의 정보를 담을 수 있습니다. 토큰의 서명은 헤더, 페이로드, 비밀 키를 사용하여 생성되며, 서버는 이 서명을 통해 토큰의 유효성을 검증합니다.

• 반면, OAuth(Open Authorization)는 사용자의 인증과 권한 부여를 위한 프로토콜입니다. 주로 사용자가 다른 웹 사이트나 애플리케이션에 로그인할 때 사용됩니다. OAuth는 클라이언트 애플리케이션이 자원에 접근하기 위해 사용자의 동의를 얻고, 제한된 액세스 토큰을 발급받아 사용합니다. 보통 Bearer token을 발급합니다.

• 요약하자면, JWT는 클라이언트와 서버 간의 인증을 처리하기 위한 토큰이고, 토큰 자체에 정보를 포함합니다. 반면, OAuth는 사용자의 인증과 권한 부여를 위한 프로토콜로, 클라이언트가 사용자의 동의를 얻어 제한된 액세스 토큰을 발급받아 자원에 접근합니다.

출처

https://velog.io/@qjqdn1568/%EC%9D%B8%EC%A6%9D%EA%B3%BC-%EC%9D%B8%EA%B0%80%EC%9D%98-%EC%B0%A8%EC%9D%B4-%EC%9E%90%EC%84%B8%ED%9E%88-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90
https://ittrue.tistory.com/246
https://hudi.blog/oauth-2.0/
https://cl8d.tistory.com/83
https://seungyong20.tistory.com/entry/JWT-Access-Token%EA%B3%BC-Refresh-Token-%EA%B7%B8%EB%A6%AC%EA%B3%A0-RTR-%EA%B8%B0%EB%B2%95%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90
https://velog.io/@chanyoung1998/JWT-%EC%99%80-OAuth-%EC%9D%98-%EC%B0%A8%EC%9D%B4