OAUTH 인증의 이해 1

🧵 Slog
,
1

이 시리즈의 모든 글 보기 : oauth

이 슬로그는 OAuth 인증의 기본 구조를 이해하고, 닷넷 프로젝트에서 활용하는 방법에 대해 알아 보는 것을 목표로 합니다.

아시다시피, "인증"이라는 주제는 매우 광범위하고, 광범위한 만큼 많은 용어도 많이 등장하며, 무엇보다 "진화적"이라는 특성 때문에, 한 사람이 이 지식을 완벽히 업데이트하는 것이 사실 상 불가능합니다. (인증만 전문으로 개발자가 아니라면 말이죠)

그럼에도 불구하고, 그 근간을 이루는 규칙과 그 규칙의 구현 방식, 그리고, 그 규칙에서 사용하는 용어들을 명확히 이해할 필요가 있습니다.

왜냐하면, 대부분의 경우 인증을 스스로 구현하는 비효율 보다는 유상 또는 무상의 라이브러리를 사용하는 효율을 선택하는데, 각 라이브러리 마다 용어가 통일되어 있지 않고, 구현 방식도 약간의 차이가 있기 때문에, 기준이 되는 지식이 없으면 라이브러리를 사용하는데 어려움을 느낄 수 있습니다.

인증은 진화 중

인증이 진화적인 이유는 보안 수단이기 때문입니다.

보안은 새로운 공격 패턴으로 현재의 보안 방식이 무너지면, 이를 막기 위한 수단이 도입되거나, 완전히 새로운 형식으로 변경되는 일을 반복합니다.

이는, 현재 시점에 널리 인정되는 인증 표준 혹은 인증 방식도 언제든 변경될 가능성이 있음을 의미합니다.

이 글에서 다룰, OAuth 및 그것의 구현 스펙인 OIDC(OpenId Connect) 도 마찬가지입니다.

뿐만 아니라, 2024년 현재, 많은 인증 서비스들은 OAuth 표준(을 바탕으로하는 OIDC)을 따르는 인증 서비스도 제공하는데 그치지 않고, 그것의 약점을 보완한 자기만의 방식으로 동작하는 인증 서비스도 제공하기도 합니다. 물론 그 서비스도 OAuth 표준을 따릅니다.(뭔 말인지…)

예를 들어, GitHub 가 제공하는 인증 서비스를 살펴 보면, 인증 서비스의 클라이언트를 가리킬 때, OAuth apps과 GitHub Apps 라는 두 가지 용어가 등장합니다.

전자는 OAuth 표준을 따르는 인증 서비스의 클라이언트를 가리키고, 후자는 깃허브만의 인증 서비스의 클라이언트를 가리킵니다.

Differences between GitHub Apps and OAuth apps - GitHub Docs

글의 내용을 보시면 아시겠지만, GitHub Apps도 OAuth 표준을 따른다고 명시하고 있습니다.

이렇게 업계 표준을 보완한 자체 인증 방식을 추가하는 추세는 깃허브 뿐만 아니라 다른 서비스들에게도 확대되고 있으며, 결국은 다시 OAuth 가 되었든 새로운 표준이 되었든, 업계 표준의 변경을 유발할 것입니다.

용어의 혼란

인증의 이해를 어렵게 하는 또 다른 요인 중 하나는 용어의 혼란입니다.

현재 데이터 보안은 보통 두 단계로 나누는 것이 표준적인 절차로 굳혀졌습니다.

  • 인증, Authentication
  • 인가, Authorization

그런데, 이 두 용어는 구현 시점에 따라 혹은 구현자 마다, 다른 이름으로 혹은 혼용해서 사용하는 경우가 많습니다.

대표적인 예로, Http 해더 중 인증(Authentication)과 관련된 해더의 이름이 "Authorization"입니다.

이 혼용은 이 해더가 보안의 개념이 인증과 인가로 분리되어 자리 잡기 전에 도입되었기 때문인 것 같습니다.

뿐만 아니라, 닷넷 개발자에게 익숙한 ClaimsPrincipal 이라는 개념은 Asp.Net Core 혹은 닷넷에서만 사용하는 개념입니다.

다음 글에서는 본격적으로 OAuth 에 등장하는 개념에 대해 알아 보도록 하겠습니다.

8개의 좋아요
2

대단하시네요 인증 인가 이것 차이를 헤더에 Authorization 이 초기에 혼용해서
혼돈이 온다 이런것을 어떻게 아신것예요?

1개의 좋아요
3

제가 뭐 천재라서 알아 냈겠습니까? ^^

사실 저도 처음 봤을 때 혼란스러웠고, 이 글을 작성하기로 맘 먹고 자료 조사하다가, Reddit, Stack overflow 등의 답글, 유/무료 강좌, 오랜 경험을 가진 전문가들의 블로그를 읽다 보면 그런 뉘앙스의 내용이 드문드문 숨어 들어 있더군요.

제가 전문적으로 글 쓰는 사람이 아니라서, 그 출처를 전부 갈무리하지는 않아서 조금 아쉽네요.

결론적으로, 인증과 관련한 규격은 태어난 지 얼마 안되었고, 지금도 변화 중이라는 점을 알게 되었습니다.

사실, 이 글을 쓰려고 맘먹은 이유도, 2023 년에 씌여진 OAuth 인증 관련 예제가 2024년에 제대로 동작하지 않는 것을 발견하고부터입니다.

인증은 법적인 책임을 질 수도 있는 상당히 무거운 주제인데, 뼈대를 알지 못 한채, 무작정 외부 코드에 의존해서는 안되겠다는 생각이 들더군요.

5개의 좋아요
4

요즘 관심이 많은 주제네요. MSA SSO를 고민하다보니 API Gateway도 있고 말이죠.

인증/인가 용어 구분은 한국어로도 어렵더라고요. 일상에서 일반적으로 구분하는 한자어가 아닌지라 신원인증/권한인가 이렇게 외우는데 그래도 헷갈립니다. 혹은 구분하기위해서 한자어를 만들었겠죠.

인증/인가에 쓰이는 보안키도 알아야하는데요. 액세스키며 토큰이며 대칭키와 비대칭키등.
api 키라고 불리웠던 것은 단순 동일문자열 검증방식이고
대칭키는 시크릿키를 상호공유해야 상호검증이 가능한데 대칭키만 이해하고 있다가 비대칭키는 공유키만으로도 검증이 가능하다는걸 알게되고⋯

git 레포지토리 / 도커 공유에 있어서는 또 이런 비밀문자열은 Prod에 포함이 안되게 해야하는데 다양한 옵션이 있고 뭐가 맞는지도 모르겠고 공유상대는 이해하고있는건가 하는 의문이 있습니다.

문제는 이런걸 다 알아야한 다는 겁니다. 쿠키와 세션은 말할 것도 없고요.

그런데 닷넷은 프레임워크단에서 마련해놓은게 많아서 직접명시 안해도 되는 것들이 많은데요. 이런 고도화는 모르는 사람입장에서는 동작흐름을 이해하기 쉽지않고 모르면 아예 못쓴다는 점이 있죠. 숨겨져있으니까 더 모르겠는 그런거 말이죠.

웹개발의 장벽은 보안에 있어서 all or nothing 이라는 점 같아요. 웹개발을 하려면 모든걸 알고 적용해야한다는 거죠. 거기다 데이터유효성 검사 방어적인 코드까지 작성하다보면 끝이 안나는 것 같습니다.

3개의 좋아요
5

저도 인증에 관해서 연구할때 알아낸것

HttpContext.SignInAsync

httpcontext 인증메커니즘을 .net 이 어찌 어찌 포장하고 있고

Middleware 에서 이걸 자동으로 통과 시킨다는 생각이었습니다.

아마도 Stateless http 프로토콜이니 헤더에 잘 포장되서 가는것이 아닐까 싶어요

1개의 좋아요
6

MS 문서에선 항상
authentication and authorization 두 개를 같이 표기하던데 말이죠,
괜히 그렇게 한 게 아닐 것 같다는 생각이 많이 듭니다.

1개의 좋아요
7

닷넷(코어)에서는 비로그인 신원 또한 Authentication으로 티켓을 발급하고 인가 또한 '아무런 권한이 없음’으로 인가하는 형태여서가 아닐까 합니다.

2개의 좋아요
8

“Guest” 내지는 “Anonymous” 계정에 대한 사용 권한(또는 이용 가능한 범위)을 준다고 설명할 수도 있겠네요…
맞는 말씀이신 것 같습니다.

1개의 좋아요