글을 쓰게 된 이유에 대해서..
이번 글은 인가를 위한 프로토콜인 OAuth2.0과 이를 기반으로 탄생한 인증 목적의 OIDC 프로토콜이 무엇 인지에 대해서 공부한 과정을 기록하려 합니다.
진행하고 있는 사이드 프로젝트를 포함해서 다양한 개발에 참여함에 따라 인증과 인가에 대한 부분은 필수적으로 알고 있어야 하는 개념이며, OAuth2.0과 OIDC라는 개념 또한 공부해야 한다는 필요성이 있어 공부하게 되었고, 그 과정에 대한 기록입니다.
앞서 OAuth2.0은 인가를 담당하고, OIDC는 인증을 위한 프로토콜이라 설명했는데 두 가지 개념을 정리하기에 앞서 인증과 인가에 대한 개념에 확신이 없어 다시 한번 정리하는 것부터 시작했습니다.
인증과 인가에 대한 개념은
chatGPT와 다양한 기술 블로그 개념들을 통해 공부한 결과 다음과 같이 정리할 수 있었습니다.
- 인증(Authentication)은 사용자 신원 확인 및 검증이 목적 → 즉, 사용자 식별이 목적
- 인가(Authorization)는 사용자에게 특정 자원에 접근할 수 있는 권한을 부여하고자 결정하는 과정
정리하자면, 인증을 통해 사용자 정보를 확인하고 그 결과로 인가(권한 부여)를 하는 것!
과거의 인증과 인가 방식
과거에는 username(id), password를 이용해서 사용자 인증을 하고, 쿠키를 통해 인가를 하는 단순한 방식으로 개발을 했다고 합니다.
하지만, 이러한 방법은 모두들 알 듯이 보안과 유지 보수에서의 문제점으로 이어졌고, 이에 대한 해답으로 최근에는 OAuth2.0과 OIDC(Open ID Connect)를 채택하고 있다고 합니다.
그렇다면 OAuth2.0이란?
이제 OAuth2.0부터 알아보자.
OAuth2.0은 인가(authorization)를 위한 프로토콜이고, client application이 resource에 대한 access 권한을 얻기 위해서 사용합니다.
→ 그냥 사용자 인가 과정이라는 말이다. 인가 목적인 만큼 OAuth2.0은 자체적으로 인증 기능을 제공하지 않는다
→ 이러한 이유로 client application이 resource server에 요청을 보낼 때 사용자에 대한 명확한 식별이 불가능하다.
중간 정리를 하자면, OAuth2.0은 Authorization 즉, 인가를 위한 프로토콜인 것이죠
미리 스포를 하자면, OIDC(Open ID Connect)는 Authentication, 즉 인증 기능을 위해 OAuth2.0을 확장한 프로토콜이다.
OAuth2.0 Terminology
OAuth2.0에서 사용되는 용어를 정리하면, 다음과 같습니다.
- Resource owner: 사용자
- Client: 사용자의 정보를 Authorization or Resource Server에게 받고 싶은 서비스
- Authorization server: 연동 계정의 인가 서버
- Resource server: 연동 계정의 사용자 정보 보유 서버 (API를 이용해 사용자 정보 조회 가능)
- Authorization grant: 정보 제공 동의하는 행위
- Redirect URI: 인가 정보를 가지고 돌아갈 위치 (인증 및 인가 flow의 종착지)
- Access token: client가 사용자에 의해 접근 허용된 resources에 접근에 사용하는 key
Authorization Server는 뭐고? Resource Server는 뭐야??
여기서 헷갈렸던 부분이 Authorization Server와 Resource Server인데,
이름 그대로 Authorization Server는 사용자 인가 만을 담당하여, Authorization Code (login token)을 client에게 전달하며, 이렇게 발급받은 Authorization Code를 이용해 다시 Access Token을 발급해 주는 역할을 수행합니다.
Resource Server의 경우 Authorization Server에게 인가 받아 발급받은 Access Token를 보유한 요청을 대상으로 데이터(자원)를 제공하는 역할을 수행한다고 이해할 수 있었습니다.
Redirect URI
redirect URI가 당연히 리다이렉션 되는 위치인 것은 알겠으나, 대체 왜 필요할까?
이를 이해하기 위해서는 OAuth2.0 프로토콜이 동작하는 방식을 알아야 합니다.
앞서 Authorization Server에서 Authorization Code를 이용해 Access Token를 발급 받는다고 이해한 바가 있습니다.
바로 여기서 Authorization Code를 Client Application이 제공한 redirect URI에 URL을 통해 전달합니다.
[그림] 들어가야 한다. → OAuth2.0 흐름에 대한 그림 필요
추가 용어 설명
위의 개념을 다시 순서대로 정리하자면,
client는 Authorization Server를 통해서 연동 계정에 대한 인증 및 인가 과정을 진행하고, 이 과정에서 정보 제공 약관에 동의 및 authorization code(login token)을 제공받습니다.
client는 authorization code를 받고, 접근 허용된 resources 조회를 가능하게 하기 위해 authorization code를 이용해서 access token을 발급받게 되는데, 이렇게 받은 access token을 이용해 Resource server로부터 resources 조회 가능합니다.
몇 가지 용어를 더 살펴볼까요?
- Scope: 제공하려는 resources 범위
- Consent: Client에서 수락을 요청하는 접근 권한들
- Back Channel (highly secure channel): SSL로 encrypted 된 HTTPS 프로토콜을 통한 통신 과정과 같이 보안이 철저한 채널을 back channel이라 부른다.
- Front Channel (less secure channel): 브라우저 상의 통신과 같이 외부에 공개되어 있는 영역에서의 통신 채널을 front channel이라 부른다.
브라우저를 통해 통신하는 경우 웹 상에 모든 정보가 공개되기 때문에, 타인이 코드를 변경하거나 작업을 의도와 다르게 동작하도록 변경 가능합니다.
서버 간 통신은 보안을 보장할 수 있고, 신뢰할 수 있으나 웹 브라우저에서 이루어지는 통신은 보안을 보장할 수 없습니다. (front channel을 통한 통신이기 때문)
위 용어를 설명한 이유 → OAuth2.0 인가 과정 속에서도 back channel, front channel 두 가지 채널을 이용해서 통신하고, 두 가지 채널 사용 목적은 보안 상의 이유에서 기인함
카카오로 대응해서 이해해 보자.
카카오 플랫폼을 통해 OAuth2.0 인가를 받는 플로우에 대한 설명이 앞서 설명한 개념과 대응되어 추가되어야 한다.
카카오 연동 로그인을 사용하면, 다음과 같은 흐름을 통해 카카오 인증 서버를 통해 authorization code를 발급받고, 이를 이용해서 카카오 API 서버에 접근해 원하는 데이터를 획득할 수 있도록 허용하는 access token을 받게 됩니다.
https://developers.kakao.com/docs/latest/ko/kakaologin/common#intro-login-process
Kakao Developers
카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.
developers.kakao.com
위의 링크를 타고 들어가면, 카카오 로그인을 통한 서비스 로그인 과정에 대해 보다 자세히 설명한 sequence diagram을 확인하실 수 있습니다.
카카오 연동 로그인을 활용해 사용자는 카카오에 로그인을 하는 과정을 통해 카카오 유저에 대한 인증을 받고, 유효한 로그인 과정을 거치고 난 뒤에는 인가를 받게 됩니다.
따라서 저희가 어떠한 서비스를 개발하고, 카카오 연동 로그인을 적용하면, 사용자가 카카오 로그인 과정을 거친 뒤에 카카오 API 서버에 접근하여 허용된 권한에 따른 정보를 조회할 수 있는 access token을 발급받게 되고, 이를 통해 resource server (카카오 API 서버)에 접근하여 데이터 조회가 가능한 구조를 갖게 됩니다.
OIDC(Open ID Connect) 프로토콜이란??
OAuth 2.0은 Authorization을 위해 만들어진 protocol로 사용자의 정보에 접근할 권한을 인가하는데 집중하고 있습니다.
이에 따라서 사용자의 신원 파악과 정보를 확인하는 authentication 과정에 대한 과정을 추가하기 위해 Open ID Connect 표준 프로토콜이 만들어졌고, OIDC는 OAuth2.0을 기반으로 인증 과정이 덧붙여진 것으로 이해 가능
Authentication을 위한 방법으로 Authorization server에게 기존에는 scope로 원하는 정보의 범위를 전달했다면, OIDC는 openid profile을 요청합니다.
그다음 이에 대한 응답으로 Authorization code을 받고, 이를 이용해서 다시 Authorization Server로부터 Access token, Open ID token(ID token)을 함께 발급받는데, 이 정보가 JWT 양식으로 발급됩니다.
(당연하게도 authorization code은 jwt 형태가 아니다. 왜냐하면, 이 둘은 그냥 잠긴 방 문을 해제하는 카드 키의 역할 만을 수행, 따라서 토큰이 추가 정보를 포함할 필요가 없다. → 나는 이걸 헷갈리고 있었음)
access token의 경우 refresh token과 분리하여 유효 기간을 짧게 가져가 refresh token을 이용해 갱신하며 사용하는 형태를 띨 수 있고, 이러한 경우 토큰에 유효 기간에 대한 정보를 포함해야 하기 때문에, JWT 형태를 갖는거죠
JWT token → 아무 때나 사용하는 것이 아니라 토큰 자체적으로 어떠한 정보를 포함하고자 할 때 사용하는 토큰의 형태인 것
OAuth2.0과 OIDC의 구분 포인트
OAuth2.0을 사용하면, 인가 과정을 사용하고
OIDC는 인증을 위해(사용자 식별을 위해) 추가적으로 유저 정보를 담은 Open ID Token을 Authorization server에게 요청 및 발급받으며, 해당 토큰은 JWT 형태의 토큰입니다.
이에 따라 안전하게 웹 통신을 통해 사용자 정보를 전송받을 수 있습니다.
JWT(JSON Web Token)는 JSON을 사용하여 정보를 표현하고, 디지털 서명을 사용하여 정보를 검증합니다.
주로 웹 및 모바일 애플리케이션에서 사용자 인증 및 정보 교환에 널리 사용됩니다.
마무리 정리
그렇다고 해서 OAuth2.0보다 발전된 모델이 OIDC인 것은 아닙니다.
그저 사용 목적에 따라서 Authentication에 대한 필요성으로 인해 OAuth2.0 기반에서 OIDC가 만들어진 것이지, OAuth2.0을 사용하는 것이 적합한 모델 또한 여전히 존재합니다.
이뿐만 아니라 목적에 따라서 다양한 방식으로 authenticaiton 및 authorization을 위한 프로토콜 사용 방법이 존재합니다.
<참고한 자료>
https://www.youtube.com/watch?v=996OiexHze0
ChatGPT
'TIL(Today I Learned)' 카테고리의 다른 글
| Window 환경에서 putty를 이용한 EC2 환경 접속 방법 기록 (0) | 2023.08.22 |
|---|---|
| [삽질 기록] YAML 파일 작성 시 double quotes를 사용하는 경우 (0) | 2023.08.21 |
| [삽질 기록] in-memory DB로 h2 사용하는 방법 (0) | 2023.08.18 |
| [Java] String, StringBuilder, StringBuffer 파고 들어보기 (0) | 2023.08.04 |
| Thymeleaf에 대한 정리 (0) | 2023.07.28 |
댓글