Oauth2.0과 OpenID Connect 비교

Oauth 2.0이란 ?

Oauth란 권한 허가를 위한 개방형 표준 프로토콜이다.

이 프로토콜에서는 Client 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공한다.

예를 들어, 구글, 네이버 등에서 제공하는 간편 로그인 기능도 Oauth2.0 프로토콜을 기반으로 사용자 인증 기능을 제공한다.

Oauth 2.0 주요 용어

Oauth를 이해하기 전에 먼저 역할과 기본 사항에 대해 알고 있어야 한다.

역할

리소스 소유자(사용자) - 인증 흐름의 리소스 소유자는 일반적으로 애플리케이션 사용자 또는 OAuth 용어로 최종 사용자 입니다.

클라이언트 - 보호된 리소스에 대한 액세스를 요청하는 애플리케이션입니다.

리소스 서버 - 리소스 서버는 리소스 소유자의 데이터를 호스팅하거나 액세스를 제공합니다.

권한 부여 서버 - ID 공급자 또는 IdP 라고도 하며 최종 사용자의 정보, 액세스 권한 및 인증 흐름의 당사자 간의 신뢰 관계를 안전하게 처리합니다. 권한 부여 서버는 사용자가 로그인(인증)한 후 앱 및 API가 리소스에 대한 액세스 권한을 부여, 거부 또는 취소(권한 부여)하는 데 사용하는 보안 토큰을 발급합니다.

용어

인증(Authentication):
접근 자격이 있는지 검증하는 단계를 말합니다.

인가(Authorization):
자원에 접근할 권한을 부여하는 것입니다. 인가가 완료되면 리소스 접근 권한이 담긴 Access Token이 클라이언트에게 부여됩니다.

권한 부여 4가지 방식 - Authorization

Oauth2.0 프로토콜에서는 다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따른 프로토콜을 4가지 종류를 구분하여 제공한다.

기본적인 권한 부여 프로우는 아래와 같다

1. 클라이언트는 리소스 소유자(사용자)에게 권한 부여를 요청합니다.

2. 사용자가 권한을 부여하면 클라이언트는 권한 부여 서버에 권한 부여를 전달합니다.

3. 권한 부여가 유효하면 권한 부여 서버는 새로 고침 및/또는 ID 토큰과 함께 액세스 토큰을 반환합니다.

4. 이제 클라이언트는 해당 액세스 토큰을 사용하여 리소스 서버에 액세스합니다.

1. Authorization Code Grant | 권한 부여 승인 코드 방식

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식

2. Implicit Grant │ 암묵적 승인 방식

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식입니다.

암시적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급

3. Resource Owner Password Credentials Grant │ 자원 소유자 자격증명 승인 방식

간단하게 username, password로 Access Token을 받는 방식

4. Client Credentials Grant │클라이언트 자격증명 승인 방식

클라이언트의 자격증명만으로 AccessToken을 획득하는 방식

---

OIDC 란?

OIDC는 OAuth 2.0 프로토콜의 상위 계층에서 인증을 담당하는 프로토콜이다.

OpenID Connect는 Oauth2.0의 상위 계층에서 같이 사용 됨으로 Access 토큰과 함께 ID 토큰을 전달 받는다.

이 ID 토큰은 JWT(JSON Web Tokens)를 통해 암호화 사용자 정보를 비롯한 다양한 정보를 HTTP 헤더의 최대 사이즈인 4KB 이내로 저장된다.

이 ID 토큰에는 User의 정보를 얻을 수 있는 데이터가 있다.

Oauth2.0와 OIDC 비교

OpenID의 주요 목적은 인증(Authentication)이지만, OAuth의 주요 목적은 인가(Authorization)이다.

인증과 인과는 무엇인가 ?

인증은 사용자의 신원을 검증하는 것이다.
가장 기본적인 비밀번호 인증 방식부터, 지문 인식등 과 같이 사용자를 식별하는 과정이다.

인가는 권한을 부여하는 것이다.
A 사용자에게는 Admin 권한을 부여하고, B 사용자에게는 Owner 권한을 부여하는 등 특정 리소스에 대한 접근 권한을 나누기 위해서 사용 한다.

( 이는 HTTP response code의 401과 403의 차이와 비슷하다고 생각한다.
401 Unauthorized error는 익명의 사용자가 인증을 하지 않았을 경우 발생하는 것이고, 403 Forbidden error는 로그인을 하였으나 권한이 없는 사용자인 경우 발생한다. )

OpenID의 주요 목적은 인증이다. OpenID를 사용한다는 것은 본질적으로 로그인을 하는것과 같다.

물론 Oauth에서도 인증 과정이 있다. 권한을 부여하기 위해서 그 조전에 인증 절차를 필요로 한다. 그렇지만 본질적인 목적은 API호출의 권한을 확인 하는 것이다.

Oauth2.0의 결과인 access_token을 통해 인가를 확인하고
OIDC의 결과인 ID_token을 통해 인증을 확인한다.

Oauth2.0 Access_token을 이용한 인증

위에서 말했듯, Oauth2.0 방식을 통해서도 인증을 할 수 있지만 인증 수단으로 사용시 보안 결함이 발생 할 수 있다.

인증 수단으로 사용하게 되면 아래와 같은 위험성들이 있다.

1. Access_token은 user인증 이후 발급 되기 때문에 인증의 증거로 간주되기 쉬우나, user에 대해 불투명하게 설계 되기 때문에 유저 정보에 대해 어떠한 정보도 말해주지 않는다.

2. Access_token을 이용해 API에 접근하는 것을 인증의 증거로 간주하는 경우가 있는데, 이는 잘못된 생각이다. Access_token은 refresh_token이나 다른 방식을 통해서도 발급이 가능하다.

3. Access_token은 생명주기가 있다. 유저정보가 삭제 된다 하더라도, Access_token은 만료되지 않고 보호된 자원에 접근할 수 있다.

4. Access_token은 탈취 위험성이 있어 Access_token가 인증된 것처럼 위장하는 위험이 있다.

OIDC ID_token을 이용한 인증

ID_token은 위에서 봤듯이 JWT토큰을 이용해 암호화 되어 있다.
서버는 ID_token을 받은 후 서버측에서 ID_token을 검증 후, iser 정보를 뽑아내 database의 값과 비교를 통해 인증을 확인한다.

위 절차대로 진행 된다면 Oauth2.0 Access_token을 이용한 인증할때의 위험성에 대한 문제를 모두 해결 할 수가 있다.

출처

https://6991httam.medium.com/oauth%EB%9E%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-openid-8c46a65616e6
https://nordicapis.com/what-is-openid-connect/