■(꿀팁)-OAuth는 무엇입니까?

 

(꿀팁) OAuth는 무엇입니까?

OAuth가 실제로 무엇인지에 대해 많은 혼란 이 있습니다.

어떤 사람들은 OAuth가 로그인 흐름 (예 : Google 로그인으로 애플리케이션에 로그인할 때)이라고 생각하고 어떤 사람들은 OAuth를 "보안 문제" 라고 생각하며 그 이상을 잘 모릅니다.

저는 OAuth가 무엇인지 보여 드리고, 어떻게 작동하는지 설명하고, OAuth가 애플리케이션에 어떻게 그리고 어디에서 도움이 될 수 있는지에 대해 알려 드리겠습니다.

 

OAuth 란?

 

OAuth (Open Authorization)는 제3자 애플리케이션이나 서비스가 사용자의 인증을 위해 다른 서비스의 인증 정보를 안전하게 사용할 수 있게 해주는 개방형 표준 프로토콜입니다. 주요 목적은 사용자가 자신의 인증 정보(예: 비밀번호)를 제공하지 않고도, 다른 애플리케이션 또는 서비스에 대한 접근 권한을 부여할 수 있는 것입니다.

OAuth의 주요 구성 요소는 다음과 같습니다:

1. 사용자(End User): 서비스에 접근하고자 하는 사용자입니다.

2. 서비스 제공자(Service Provider): 사용자가 접근하고자 하는 서비스를 제공하는 웹 사이트 또는 애플리케이션입니다.

3. 클라이언트(Client): OAuth를 통해 접근 권한을 얻고자 하는 제3자 애플리케이션입니다.

4. 인증 제공자(Authorization Provider): OAuth 인증 프로세스를 관리하고, 사용자의 인증 정보를 제공하는 서비스입니다.

 OAuth는 인증을 위한 개방형 표준이며 누구나 구현할 수 있습니다.

보다 구체적으로, OAuth는 앱이 클라이언트 애플리케이션에 "보안 위임 액세스"를 제공하는 데 사용할 수 있는 표준입니다. OAuth는 HTTPS를 통해 작동하며 자격 증명이 아닌 액세스 토큰을 사용하여 장치, API, 서버 및 애플리케이션을 승인합니다.

OAuth에는 OAuth 1.0a 및 OAuth 2.0 의 두 가지 버전이 있습니다.이러한 사양은 서로 완전히 다르며 함께 사용할 수 없습니다. 서로 하위 호환성 이 없습니다 .

어느 것이 더 인기가 있습니까? 좋은 질문입니다! 오늘날 OAuth 2.0은 가장 널리 사용되는 OAuth 형식입니다. 이제부터는 "OAuth" 라고 말할 때마다 OAuth 2.0에 대해 이야기하는 것입니다. 사용하게 될 가능성이 가장 높기 때문입니다.

 

왜 OAuth인가?

OAuth는 직접 인증 패턴에 대한 응답으로 생성되었습니다. 이 패턴은 사용자에게 사용자 이름과 암호를 입력하라는 메시지가 표시되는 HTTP 기본 인증으로 유명해졌습니다. 기본 인증은 여전히 ​​서버 측 애플리케이션에 대한 API 인증의 기본 형식으로 사용됩니다. 각 요청과 함께 사용자 이름과 비밀번호를 서버에 보내는 대신 사용자는 API 키 ID와 비밀을 보냅니다. OAuth 이전에 사이트는 사용자 이름과 비밀번호를 양식에 직접 입력하라는 메시지를 표시하고 사용자 데이터 (예 : Gmail 계정)에 로그인합니다. 이를 종종 암호 안티 패턴이라고

웹을 위한 더 나은 시스템을 만들기 위해 SSO (Single Sign-On)에 대한 연합 ID가 생성되었습니다. 이 시나리오에서 최종 사용자는 자신의 ID 공급자와 대화하고 ID 공급자는 사용자를 인증하기 위해 애플리케이션에 전달하는 암호화 서명된 토큰을 생성합니다. 응용 프로그램은 ID 공급자를 신뢰합니다. 신뢰 관계가 서명 된 주장과 함께 작동하는 한 괜찮습니다. 아래 다이어그램은 이것이 어떻게 작동하는지 보여줍니다.

 

Federated identity는 2005 년 3 월 15 일에 발표된 OASIS 표준 인 SAML 2.0에 의해 유명해졌습니다. 이것은 큰 사양이지만 주요 두 가지 구성 요소는 인증 요청 프로토콜 (일명 Web SSO)과 ID 속성을 패키 징하고 서명하는 방식입니다. SAML 션. Okta는 SSO 치 클릿으로 이를 수행합니다. 우리는 메시지를 보내고 어설 션에 서명합니다. 어설 션 안에 사용자가 누구인지, Okta에서 왔는지가 표시됩니다. 그것에 디지털 서명을 치고 당신은 갈 수 있습니다.

 

SAML

SAML은 인증에 사용되는 개방형 표준입니다. SAML은 "Security Assertion Markup Language"의 약자로, 보안 주장 마크업 언어라고 합니다. SAML은 인증과 권한 부여를 위한 표준 프로토콜로 사용되며, 클라이언트와 서비스 제공자 간에 인증 및 권한 정보를 안전하게 전달하는 데 사용됩니다.

 XML(Extensible Markup Language) 형식을 기반으로 하는 웹 애플리케이션은 SAML을 사용하여 IdP(ID 공급자)와 SP(서비스 공급자) 간에 인증 데이터를 전송합니다.

기술 업계에서는 사용자가 여러 도메인에서 독립적인 여러 웹 응용 프로그램에 액세스해야 하는 인증 프로세스를 단순화하기 위해 SAML을 만들었습니다. 

SAML은 주로 웹 기반의 단일 로그인 SSO(Single Sign-On) 시나리오에서 사용됩니다. SAML 이전의 SSO(Single Sign-On)이 있었지만 동일한 도메인 내에서만 실행 가능한 쿠키에 의존했습니다. 

SAML 인증을 통한 SSO 접근 방식은 사용자가 여러 사용자 이름과 암호를 기억할 필요가 없이,  SSO 시스템을 통해 사용자가 여러 애플리케이션 또는 서비스에 대해 단일 자격 증명을 사용하여 로그인할 수 있는 방법을 제공합니다. 이를 통해 사용자는 여러 개별 로그인 절차를 수행하지 않고도 다양한 애플리케이션에 액세스할 수 있습니다.

SAML은 클라이언트와 서비스 제공자 사이의 인증과 권한 부여에 대한 보안을 제공하기 위해 암호화와 서명과 같은 보안 메커니즘을 사용합니다. 이를 통해 사용자의 신원 정보가 안전하게 전달되고 위조를 방지할 수 있습니다.

SAML의 주요 프로세스와  기능

• 주장(Assertion): SAML 주장은 사용자의 신원과 권한 정보를 포함하는 사용자 인증을 담은 XML 문서입니다.
• 인증 요청(Authentication Request): 클라이언트가 서비스 제공자에게 사용자를 식별하는 데 사용되는 정보와 원하는 서비스에 대한 정보를 포함하여 사용자 인증을 요청을 합니다.
• 응답(Reponse): 서비스 제공자가 클라이언트에게 응답으로 보내는 것으로, 주장(Assertion)을 포함합니다. 사용자의 신원과 권한 정보가 포함하여 사용자를 인증하고 권한을 부여할 수 있습니다.

 

OAuth 및 API

 

API (Application Programming Interface)는 소프트웨어 애플리케이션 간에 서로 상호작용할 수 있도록 하는 인터페이스입니다. API는 프로그램이 서로 통신하고 데이터를 교환할 수 있도록 허용하는 메서드, 프로토콜, 도구의 모음입니다.

API를 빌드하는 방식에도 많은 변화가 있었습니다.2005 년에 사람들은 웹 서비스 구축을 위해 WS- *에 투자했습니다. 이제 대부분의 개발자는 REST 및 상태 비 저장 API로 이동했습니다. REST는 간단히 말해서 네트워크를 통해 JSON 패킷을 푸시하는 HTTP 명령입니다.

API를 통해 애플리케이션은 다른 애플리케이션의 기능을 활용하고, 데이터를 가져오고, 서비스를 호출할 수 있습니다. API는 일종의 계약으로서, 개발자가 특정 요청을 보내면 그에 대한 응답이 제공됩니다.

예를 들어, 소셜 미디어 플랫폼의 API를 사용하면 애플리케이션이 해당 플랫폼의 사용자 데이터에 접근하거나 게시물을 작성할 수 있습니다. API는 웹 API(HTTP 기반)뿐만 아니라 다양한 형태로 존재하며, 일반적으로 JSON 또는 XML 형식으로 데이터를 주고받습니다.

 

OAuth 는

OAuth는 REST / API에 대한 위임된 권한 부여 프레임 워크입니다. 이를 통해 앱은 사용자의 암호를 제공하지 않고도 사용자 데이터에 대한 제한된 액세스 (범위)를 얻을 수 있습니다. 인증에서 인증을 분리하고 다양한 장치 기능을 다루는 여러 사용 사례를 지원합니다. 서버 간 앱, 브라우저 기반 앱, 모바일 / 네이티브 앱 및 콘솔 / TV를 지원합니다.

이것은 호텔 키 카드처럼 생각할 수 있지만 앱용입니다. 호텔 키 카드가 있으면 객실에 액세스 할 수 있습니다. 호텔 키 카드는 어떻게 받습니까? 이를 받으려면 프런트 데스크에서 인증 절차를 거쳐야 합니다.키 카드를 인증하고 얻은 후 호텔 전체의 리소스에 액세스 할 수 있습니다.

OAuth 프로세스는 다음과 같이 진행됩니다:

1. 클라이언트 애플리케이션이 사용자를 인증할 수 있는 권한을 요청합니다.

2. 사용자는 클라이언트에 대한 접근 권한을 부여하기 위해 인증 제공자에 로그인합니다.

3. 인증 제공자는 사용자에게 접근 권한을 요청하는 클라이언트에 대한 선택 권한을 부여합니다.

4. 사용자는 권한 부여를 승인하고, 인증 제공자가 클라이언트에게 사용자의 인증 정보를 안전하게 전달할 수 있도록 허용합니다.

5. 클라이언트는 받은 인증 정보를 사용하여 서비스 제공자로부터 사용자의 데이터에 접근할 수 있습니다.

 

 

OAuth Central 구성 요소

 

OAuth의 주요 구성 요소는 다음과 같습니다:

1. 클라이언트(Client):
OAuth 인증을 위해 인증 제공자에게 접근 권한을 요청하는 애플리케이션이나 서비스입니다. 클라이언트는 보호된 리소스에 접근하려는 사용자를 대신하여 인증을 수행합니다.

2. 리소스 소유자(Resource Owner):
사용자로서 보호된 리소스에 대한 액세스 권한을 가지고 있습니다. 일반적으로 웹 애플리케이션에서는 엔드 유저가 리소스 소유자 역할을 합니다.

3. 인증 제공자(Authorization Provider):
사용자의 인증 정보를 관리하고 인증을 수행하는 서비스입니다. 인증 제공자는 클라이언트에 대한 접근 권한을 부여하고, 액세스 토큰을 발급합니다.

4. 리소스 서버(Resource Server):
보호된 리소스를 호스팅하고 관리하는 서비스입니다. 리소스 서버는 클라이언트가 액세스하려는 리소스를 보유하고 있으며, 클라이언트에 대한 인증 및 권한 부여를 처리합니다.

5. 인가 서버(Authorization Server):
OAuth 인증 프로세스를 관리하고 인증 제공자와 리소스 서버 사이의 통신을 조정합니다. 일반적으로 인가 서버와 인증 제공자는 동일한 서비스로 제공되며, 인증 제공자의 역할도 수행합니다.

OAuth 프로세스에서 클라이언트는 리소스 소유자의 인증 정보를 직접 요청하지 않고, 인증 제공자를 통해 인증을 수행합니다. 클라이언트는 사용자를 리다이렉트하여 인증 제공자에게 인증을 요청하고, 인증이 완료되면 액세스 토큰을 받아 리소스 서버에 접근합니다.

이러한 구성 요소들이 협력하여 OAuth는 보안과 권한 부여를 위한 표준 프로토콜로 사용됩니다.

 

OAuth 범위

 

OAuth에서 범위(scope)는 클라이언트가 요청할 수 있는 보호된 리소스의 범위를 지정하는 데 사용되는 매개 변수입니다. 범위는 액세스 토큰을 요청할 때 인증 제공자에게 제공되며, 클라이언트가 특정 리소스나 작업에 대한 액세스 권한을 얻을 수 있도록 허용합니다.

범위(scope)는 OAuth 인증 프로세스의 중요한 부분으로, 클라이언트가 필요한 리소스에 대한 권한만 부여받을 수 있도록 제한할 수 있습니다. 이를 통해 사용자의 데이터 및 리소스에 대한 액세스를 제어하고, 클라이언트가 필요로 하는 최소한의 권한만을 부여할 수 있습니다.

범위(scope)는 앱이 권한을 요청할 때 인증 화면에 표시되는 것입니다. 토큰을 요청할 때 클라이언트가 요청하는 권한 번들입니다. 이들은 애플리케이션을 작성할 때 애플리케이션 개발자가 코딩합니다.

예를 들어, 소셜 미디어 플랫폼의 OAuth에서 범위는 사용자의 프로필 정보, 친구 목록, 포스트 등과 같은 리소스에 대한 권한을 정의할 수 있습니다. 클라이언트가 "프로필 정보"와 "친구 목록"이라는 범위를 요청하면, 액세스 토큰은 해당 범위에 대한 액세스만을 허용하며, 다른 리소스에 대한 액세스는 거부될 수 있습니다.

OAuth의 범위는 액세스 제어와 권한 관리를 위해 유용한 기능입니다. 사용자는 클라이언트가 접근할 수 있는 범위를 제어하고, 클라이언트는 필요한 최소한의 권한만을 요청하여 보안성을 강화할 수 있습니다.

 

OAuth 행위자(Actors)

 

OAuth에서는 다음과 같은 행위자(Actors)들이 참여합니다:

1. 리소스 소유자(Resource Owner):
리소스 소유자는 보호된 리소스에 대한 액세스 권한을 가진 사용자입니다. 예를 들어, 소셜 미디어 플랫폼의 사용자가 리소스 소유자가 될 수 있습니다.  (예  Facebook은  프로필의 리소스 소유자)

2. 클라이언트(Client):
클라이언트는 리소스 소유자를 대신하여 보호된 리소스에 액세스 권한을 요청하는 애플리케이션이나 서비스입니다. 클라이언트는 인증 제공자로부터 액세스 토큰을 받아 리소스 서버에 접근합니다. 일반적으로 웹 애플리케이션, 모바일 앱, 서비스 API 등이 클라이언트 역할을 수행할 수 있습니다.

3. 인증 제공자(Authorization Provider):
인증 제공자는 사용자의 인증 정보를 관리하고 인증을 수행하는 서비스입니다. 클라이언트가 인증 제공자를 통해 리소스 소유자의 인증 정보를 확인하고, 액세스 토큰을 발급받습니다. 일반적으로 OAuth를 구현한 서비스 제공업체가 인증 제공자 역할을 수행합니다.

4. 리소스 서버(Resource Server):
리소스 서버는 보호된 리소스 데이터를 호스팅하고 관리하는 서비스입니다. 클라이언트는 액세스 토큰을 사용하여 리소스 서버에 액세스하고, 보호된 리소스에 대한 요청을 처리합니다. 리소스 서버는 액세스 토큰의 유효성을 검증하고, 클라이언트에게 요청된 리소스를 반환합니다.

5. 인가 서버(Authorization Server):
인가 서버는 OAuth 인증 메인 서버로 프로세스를 관리하고 인증 제공자와 리소스 서버 사이의 통신을 조정합니다. 일반적으로 인가 서버와 인증 제공자는 동일한 서비스로 제공되며, 인증 제공자의 역할도 수행합니다.

 

 

이러한 행위자들 간의 상호작용을 통해 OAuth는 보안과 권한 부여를 위한 표준 프로토콜로 사용됩니다. 리소스 소유자는 자신의 인증 정보를 안전하게 유지하면서 클라이언트에게 필요한 권한을 부여할 수 있으며, 클라이언트는 액세스 토큰을 통해 리소스 서버에 대한 인증 및 권한을 얻을 수 있습니다.

OAuth 명명법에서 "공개 클라이언트(Public Client)"와 "기밀 클라이언트(Confidential Client)"라는 용어가 사용됩니다. 이 두 용어는 클라이언트의 특성과 보안 요구사항을 나타내는 데 중요한 차이가 있습니다.

1. 공개 클라이언트(Public Client):

공개 클라이언트는 클라이언트의 비밀을 저장하거나 유지하지 않는 클라이언트입니다.
주로 웹 애플리케이션, 모바일 앱, 싱글 페이지 애플리케이션 등이 해당됩니다.
공개 클라이언트는 클라이언트 ID만으로 인증 제공자와 상호작용하며, 클라이언트 비밀 키를 사용하지 않습니다.
보안적으로 민감한 작업(예: 사용자의 권한을 변경하는 등)을 수행하지 않거나, 클라이언트가 최종 사용자의 관리 영역에서 실행되기 때문에 보안적인 위험이 상대적으로 낮습니다.

2. 기밀 클라이언트(Confidential Client):

기밀 클라이언트는 클라이언트의 비밀을 안전하게 저장하고 유지하는 클라이언트입니다.
서버-서버 상호작용이나 안전한 실행 환경(예: 백엔드 서비스, 데스크톱 애플리케이션)에서 주로 사용됩니다.
기밀 클라이언트는 클라이언트 ID와 클라이언트 비밀 키를 사용하여 인증 제공자와 통신합니다.
클라이언트 비밀 키를 유지함으로써 보다 안전한 통신을 보장하고, 리버스 엔지니어링이나 비밀 키 유출을 통한 보안 위험을 최소화합니다.

기밀 클라이언트는 클라이언트 비밀 키를 안전하게 보호해야 하므로, 배포되지 않는 환경이나 최종 사용자가 액세스할 수 없는 보호 영역에서 실행됩니다. 이를 통해 기밀 정보가 유출되거나 악용되는 위험을 최소화합니다. 반면, 공개 클라이언트는 클라이언트 비밀 키를 사용하지 않기 때문에 상대적으로 보안 요구사항이 덜한 시나리오에서 사용됩니다.

 

 

 

OAuth 토큰

 

OAuth에서 토큰(Token)은 클라이언트가 보호된 리소스에 액세스할 때 사용되는 인증 정보를 나타냅니다. OAuth 토큰은 리소스 소유자의 동의를 통해 발급되며, 클라이언트는 이 토큰을 사용하여 리소스 서버에 인증하고 리소스에 접근할 수 있습니다.

액세스 토큰은 클라이언트가 리소스 서버 (API)에 액세스 하는 데 사용하는 토큰입니다. 수명이 수시간 이내로 짧습니다.

OAuth에서 사용되는 주요 토큰은 다음과 같습니다:

1. 액세스 토큰(Access Token):

• 액세스 토큰은 클라이언트가 보호된 리소스에 액세스하기 위해 사용되는 주요 토큰입니다.
• 액세스 토큰은 클라이언트가 인증 제공자로부터 받으며, 리소스 서버에 제출하여 인증 및 권한 부여를 받습니다.
• 액세스 토큰은 일정 기간 동안 유효하며, 유효 기간이 만료되면 재발급해야 합니다.
• 액세스 토큰을 새로 고칠 때마다 암호화 서명된 새 토큰을 받습니다.키 순환은 시스템에 내장되어 있습니다.

 

2. 갱신 토큰(Refresh Token):

• 갱신 토큰은 액세스 토큰의 유효 기간이 만료되었을 때, 클라이언트가 새로운 액세스 토큰을 얻기 위해 사용되는 토큰입니다.
• 갱신 토큰은 보다 오랜 유효 기간을 가지며, 일반적으로 액세스 토큰보다 오래 지속됩니다.
• 클라이언트는 갱신 토큰을 사용하여 인증 제공자에게 새로운 액세스 토큰을 요청하고, 리소스 서버에 액세스할 수 있습니다.

 

3. 인증 코드(Authorization Code):

• 인증 코드는 OAuth 인증 프로세스 중에 사용되는 일시적인 토큰입니다.
• 클라이언트가 인증 제공자로부터 인가를 받은 후, 인증 코드를 받습니다.
• 이 인증 코드는 클라이언트가 액세스 토큰 및 갱신 토큰을 교환하는 데 사용됩니다.

토큰은 일반적으로 문자열 형태로 표현되며, OAuth 프로토콜을 구현한 서비스에서는 각 토큰의 유효성 검증 및 관리를 위한 메커니즘을 제공합니다. 이를 통해 클라이언트는 인증 및 권한 부여를 위해 필요한 토큰을 안전하게 관리하고 사용할 수 있습니다.

 토큰은 권한 부여 서버의 엔드 포인트에서 검색됩니다. 두 가지 주요 엔드 포인트는 권한 부여 엔드 포인트와 토큰 엔드 포인트입니다. 서로 다른 사용 사례에 따라 구분됩니다. 권한 부여 끝점은 사용자의 동의와 권한을 얻기 위해 이동하는 곳입니다. 그러면 사용자가 동의했다는 권한 부여가 반환됩니다. 그런 다음 인증이 토큰 엔드 포인트로 전달됩니다. 토큰 엔드 포인트는 승인을 처리하고 "좋습니다. 새로 고침 토큰과 액세스 토큰이 있습니다"라고 말합니다.

액세스 토큰을 사용하여 API에 액세스 할 수 있습니다. 만료되면 새 액세스 토큰을 얻으려면 새로 고침 토큰을 사용하여 토큰 끝점으로 돌아가야 합니다.

단점은 이것이 많은 개발자 마찰을 유발한다는 것입니다. 개발자를위한 OAuth의 가장 큰 문제점 중 하나는 새로 고침 토큰을 관리해야 한다는 것입니다. 상태 관리를 각 클라이언트 개발자에게 푸시합니다. 키 순환의 이점을 얻었지만 개발자에게 많은 고통을 안겨주었습니다. 이것이 개발자가 API 키를 좋아하는 이유입니다. 복사 / 붙여 넣기 만하면 텍스트 파일에 넣을 수 있고 작업을 완료할 수 있습니다. API 키는 개발자에게 매우 편리하지만 보안에는 매우 좋지 않습니다.

 

JWT (Json Web Token)

JWT( JSON Web Token)는 웹 표준으로 정의된 JSON 기반의 토큰입니다. JWT는 클레임(Claims) 기반의 액세스 토큰을 생성하고 전달하기 위해 사용됩니다. 특히, 서로 다른 시스템 간의 안전한 정보 전달을 위해 널리 사용됩니다.

JWT는 세 부분으로 구성됩니다:

1. Header(헤더):
JWT의 유형과 사용된 암호화 알고리즘 등의 정보를 포함합니다. 헤더는 JSON 형식으로 작성되며, Base64Url로 인코딩됩니다.

2. Payload(페이로드):
실제로 전달하려는 정보, 즉 클레임(Claims)이 포함됩니다. 클레임은 토큰에 대한 추가적인 정보를 나타내며, 예를 들어 사용자 식별자, 권한, 만료 시간 등이 포함될 수 있습니다. 페이로드는 JSON 형식으로 작성되며, Base64Url로 인코딩됩니다.

3. Signature(서명):
헤더와 페이로드를 조합하여 서명되어 토큰의 무결성을 보장합니다. 서명은 주로 비밀 키를 사용하여 생성되며, 서명 알고리즘에 따라 다양한 방식으로 생성됩니다.

 

JWT는 클라이언트와 서버 간의 인증 및 권한 부여를 간편하게 구현할 수 있습니다. 클라이언트가 인증되면, 서버는 JWT를 발급하고 클라이언트에게 전달합니다. 클라이언트는 이 JWT를 이후의 요청에서 헤더나 URL 매개변수로 포함하여 서버에 제공합니다. 서버는 JWT의 유효성을 검증하고, 클라이언트에 대한 액세스 권한을 부여합니다.

JWT의 장점으로는 자가수용적(Self-contained)이라는 점이 있습니다. 즉, JWT에는 필요한 모든 정보가 포함되어 있어 서버 측에서 따로 상태를 저장하거나 데이터베이스에 접근할 필요가 없습니다. 이는 확장성과 효율성을 높여줍니다. 하지만 JWT의 단점으로는 토큰 자체가 클라이언트에게 전송되므로, 토큰이 탈취되면 악용될 수 있다는 점을 유의해야 합니다. 따라서 토큰의 유효 기간을 제한하고, 보안적인 조치를 취하는 것이 중요합니다.

 

 

OAuth의 Front Channel과 Back Channel의  Token Access

 

1. Front Channel:

• Front Channel은 사용자와 상호작용하는 클라이언트 애플리케이션과 인증 제공자 간의 직접적인 통신 채널입니다.
• 일반적으로 웹 브라우저를 통해 이루어지며, 사용자 인증 및 동의 프로세스를 처리하는 데 사용됩니다.
• 사용자가 클라이언트 애플리케이션에 접근하고, 인증 제공자의 로그인 페이지로 리디렉션되어 사용자 인증 정보를 입력하고 동의를 수락할 수 있습니다.
• Front Channel은 보안 상의 제한이 있을 수 있으며, 사용자와 클라이언트 간의 상호작용에 대한 보안을 유지하기 위해 추가적인 보안 메커니즘(예: CSRF 방어)을 구현해야 합니다.

2. Back Channel:

• Back Channel은 인증 제공자와 클라이언트 애플리케이션 간의 안전한 서버 간 통신 채널입니다.
• 클라이언트 애플리케이션이 OAuth 인증 프로세스를 처리하고, 액세스 토큰과 같은 중요한 보안 정보를 안전하게 관리하는 데 사용됩니다.
• 일반적으로 클라이언트의 백엔드 서버와 인증 제공자의 서버 간의 통신을 의미합니다.
• Back Channel은 클라이언트 인증 및 토큰 교환 등 보안적으로 중요한 작업을 처리하기 때문에, HTTPS와 같은 보안 프로토콜을 사용하여 통신을 암호화하고 보호해야 합니다.
• 암호화된 통신을 통해 클라이언트 애플리케이션은 인증 제공자로부터 인증 코드를 받아 액세스 토큰과 갱신 토큰을 교환하며, 이를 사용하여 보호된 리소스에 액세스할 수 있습니다.

 

Front Channel과 Back Channel은 OAuth 인증 프로세스에서 각각 다른 역할을 수행하며, 적절한 보안 및 인증 메커니즘을 갖추어야 안전한 인증과 권한 부여를 보장할 수 있습니다.

토큰은 클라이언트 애플리케이션에서 사용되므로 사용자를 대신하여 리소스에 액세스 할 수 있습니다. 이를 백 채널이라고 합니다.백 채널은 토큰에 대한 권한 부여를 교환하기 위해 클라이언트 애플리케이션에서 리소스 서버로 직접 HTTP 호출하는 것입니다. 이러한 채널은 보유한 장치 기능에 따라 다른 흐름에 사용됩니다.

 

 

OAuth의 Front Channel 흐름은 다음과 같은 4단계로 요약할 수 있습니다:

1. 클라이언트 요청:
사용자가 클라이언트 애플리케이션에 접근하고, 클라이언트는 인증 제공자에게 사용자를 인증하고 액세스 권한을 요청하기 위한 URL을 생성합니다.

2. 사용자 인증 및 동의:
사용자는 인증 제공자의 인증 서비스 페이지에서 자신의 인증 정보를 입력하고, 동의 페이지에서 동의를 수락합니다.

3. 인증 코드 반환:
인증 제공자는 사용자의 동의 후에 인증 코드를 클라이언트 애플리케이션에게 반환합니다.

4. 액세스 토큰 요청:
클라이언트 애플리케이션은 인증 코드를 사용하여 인증 제공자에게 액세스 토큰을 요청합니다.

이 단계를 통해 클라이언트 애플리케이션은 사용자의 동의를 얻고, 인증 제공자로부터 액세스 토큰을 받아 보호된 리소스에 액세스할 수 있게 됩니다.

 

의뢰	이것은 여러 쿼리 매개 변수가 있는 GET 요청입니다 (예시 목적으로 URL 인코딩 되지 않음). 범위는 Gmail의 API에서 가져옵니다. redirect_uri는 권한 부여가 반환되어야 하는 클라이언트 응용 프로그램의 URL입니다. 이는 클라이언트 등록 프로세스 (DMV에서)의 값과 일치해야 합니다.인증이 외국 응용 프로그램으로 반송되는 것을 원하지 않습니다. 응답 유형은 OAuth 흐름에 따라 다릅니다. 클라이언트 ID도 등록 프로세스에서 가져옵니다. State는 XRSF와 유사한 보안 플래그입니다. XRSF에 대한 자세한 내용은 DZone의 "교차 사이트 요청 위조 설명"을 참조하십시오 .
응답	code권한 부여는 것입니다 반환 state이 위조 아니에요 보장하는 것입니다 그리고 그것은 같은 요청에서 입니다.

프런트 채널이 완료되면 백 채널 플로우가 발생하여 액세스 토큰에 대한 인증 코드를 교환합니다.

OAuth의 Back Channel 플로우를 통한 액세스 토큰 교환 프로세스는 다음과 같은 단계로 이루어집니다:

1. 클라이언트 인증 및 액세스 토큰 요청:

클라이언트 애플리케이션은 백엔드 서버를 통해 인증 제공자에게 클라이언트 인증과 함께 액세스 토큰을 요청합니다.

1.1 클라이언트 인증:

클라이언트 애플리케이션은 백엔드 서버를 통해 인증 제공자에게 액세스 토큰을 요청하기 전에 자신을 인증합니다.
이를 위해 클라이언트 식별자(Client ID)와 클라이언트 비밀(Client Secret)을 사용하여 인증 제공자에게 클라이언트 인증을 전달합니다.

1.2 액세스 토큰 요청:

클라이언트 애플리케이션은 백엔드 서버를 통해 인증 제공자에게 액세스 토큰을 요청합니다.
이 요청에는 사용자의 인증 정보와 요청된 권한 범위 등이 포함될 수 있습니다.

1.3 인증 제공자 인증:

인증 제공자는 클라이언트 인증과 사용자 인증을 검증한 후, 액세스 토큰 발급을 위한 인증 과정을 진행합니다.
사용자 인증이 필요한 경우, 사용자를 로그인 페이지로 리디렉션하여 인증 정보를 입력하도록 요구할 수 있습니다.

 

2. 액세스 토큰 발급 및 사용:

인증 제공자는 클라이언트 인증을 확인하고, 액세스 토큰을 생성하여 백엔드 서버로 반환합니다.
백엔드 서버는 액세스 토큰을 안전하게 저장하고, 보호된 리소스에 대한 요청 시 액세스 토큰을 사용하여 인증을 처리합니다.

2.1 액세스 토큰 발급:

인증 제공자는 액세스 토큰을 생성하고, 클라이언트 애플리케이션의 백엔드 서버로 반환합니다.
액세스 토큰은 보호된 리소스에 대한 인증 및 권한을 나타내며, 일반적으로 JWT(JSON Web Token) 형식으로 발급됩니다.

2.2 액세스 토큰 사용:

클라이언트 애플리케이션의 백엔드 서버는 액세스 토큰을 안전하게 저장하고, 보호된 리소스에 대한 요청 시 액세스 토큰을 사용하여 인증을 처리합니다.
보호된 리소스 서버는 액세스 토큰의 유효성을 검증하고, 요청된 리소스에 대한 액세스 권한을 확인합니다.
액세스 토큰 교환 프로세스는 클라이언트 애플리케이션의 백엔드 서버가 인증 제공자와 안전한 통신을 수행하여 액세스 토큰을 요청하고 수신하는 과정입니다. 이를 통해 클라이언트는 사용자의 동의와 인증을 통해 액세스 토큰을 얻고, 보호된 리소스에 대한 액세스를 안전하게 처리할 수 있습니다.

 

다음은 원시 HTTP에서  보이는 내용입니다.

의뢰	grant_type은 OAuth의 확장 성 부분입니다. 미리 계산된 관점에서 본 인증 코드입니다. 이러한 보조금을 설명하는 다양한 방법을 가질 수 있는 유연성을 제공합니다. 이것은 가장 일반적인 OAuth 흐름 유형입니다.
응답	응답은 JSON입니다. 토큰을 사용할 때 사후 대응 적이거나 사전 대응적일 수 있습니다. 사전 예방은 클라이언트에 타이머를 갖는 것입니다. 반응은 오류를 포착하고 새 토큰을 얻으려고 시도하는 것입니다.

액세스 토큰이 있으면 인증 헤더의 액세스 토큰을 사용하여 ( token_type접두사로 사용) 보호된 리소스 요청을 만들 수 있습니다.

curl -H "Authorization: Bearer 2 YotnFZFEjr1 zCsicMWpAA" \ https://www.googleapis.com/gmail/v1/users/1444587525/messages

이제 프런트 채널, 백 채널, 다른 엔드 포인트 및 다른 클라이언트가 있습니다. 다양한 사용 사례에 대해 이들을 혼합하고 일치시켜야 합니다. OAuth의 복잡성이 높아져 혼란스러워질 수 있습니다.

 

 

OAuth의 일반적인 흐름

 

OAuth는 클라이언트 애플리케이션이 인증 제공자를 통해 사용자의 인증 정보를 안전하게 확인하고, 사용자의 동의를 얻어 보호된 리소스에 대한 액세스 권한을 얻는 프로토콜입니다. 다음은 OAuth의 일반적인 흐름을 설명한 것입니다:

1. 클라이언트 애플리케이션 요청:

사용자가 클라이언트 애플리케이션에 접근하고, 애플리케이션은 인증 제공자에게 사용자 인증 및 액세스 권한을 요청하는 URL을 생성합니다.

2. 사용자 인증 및 동의:

클라이언트 애플리케이션은 사용자를 인증 제공자의 로그인 페이지로 리디렉션시킵니다.
사용자는 인증 제공자의 로그인 페이지에서 자신의 인증 정보를 입력하여 인증을 수행합니다.
인증이 성공하면, 인증 제공자는 사용자에게 애플리케이션의 요청된 권한 범위에 대한 동의를 요청하는 동의 페이지로 리디렉션시킵니다.
사용자가 동의하면, 인증 제공자는 동의한 범위의 액세스 권한을 부여합니다.

3. 인가 코드 받기:

인증 제공자는 사용자 동의 후에 클라이언트 애플리케이션에게 인가 코드(authorization code)를 반환합니다.
인가 코드는 일회성 코드로, 액세스 토큰을 받기 위한 다음 단계에서 사용됩니다.

4. 액세스 토큰 교환:

클라이언트 애플리케이션은 인가 코드와 함께 인증 제공자에게 액세스 토큰을 요청합니다.
인증 제공자는 인가 코드를 검증하고, 유효한 경우 액세스 토큰과 함께 리프레시 토큰(refresh token)을 클라이언트 애플리케이션에게 반환합니다.
액세스 토큰은 애플리케이션에서 보호된 리소스에 접근할 때 사용되며, 리프레시 토큰은 액세스 토큰이 만료된 경우 새로운 액세스 토큰을 얻기 위해 사용됩니다.

5. 액세스 보호된 리소스에 액세스:

클라이언트 애플리케이션은 액세스 토큰을 사용하여 보호된 리소스 서버에 요청을 보냅니다.
보호된 리소스 서버는 액세스 토큰의 유효성을 검증하고, 요청된 리소스에 대한 액세스 권한을 확인한 후 클라이언트 애플리케이션에 응답합니다.

OAuth 흐름을 통해 클라이언트 애플리케이션은 사용자의 동의를 얻고, 인증 제공자로부터 액세스 토큰을 받아 보호된 리소스에 대한 인증을 처리할 수 있습니다.

 

 

OAuth 흐름

 

OAuth에는 다양한 인증 흐름이 있습니다.

 

1. OAuth의 Implicit Flow(암시적 흐름)

OAuth의 Implicit Flow(암시적 흐름)은 클라이언트 애플리케이션이 사용자의 액세스 토큰을 직접 요청하는 대신, 리다이렉트된 URI를 통해 액세스 토큰을 얻는 방식입니다. Implicit Flow는 다음과 같은 특징을 가지고 있습니다:

1) 액세스 토큰 직접 반환:

암시적 흐름에서는 액세스 토큰이 직접 반환됩니다. 인가 코드 교환 단계가 없고, 액세스 토큰이 바로 클라이언트에게 전달됩니다.

2) 리다이렉트된 URI:

클라이언트 애플리케이션은 사용자 인증 및 동의 후 액세스 토큰을 수신하기 위해 인증 제공자에게 리다이렉트된 URI를 제공합니다.

3) URL 프래그먼트(#) 사용:

암시적 흐름에서는 액세스 토큰이 URL 프래그먼트 내에 포함되어 클라이언트 애플리케이션에게 전달됩니다.

암시적 흐름은 주로 클라이언트 애플리케이션이 액세스 토큰을 직접 사용해야 하는 단일 페이지 애플리케이션(SPA) 또는 웹 애플리케이션에서 사용됩니다. 일반적으로 보안 요구사항이 덜 엄격한 상황에서 사용되며, 인가 코드의 교환 과정을 생략하여 효율적인 인증 프로세스를 제공합니다. 그러나 주의할 점은 암시적 흐름에서는 액세스 토큰이 URL에 노출되기 때문에 보안상의 위험이 있을 수 있다는 점입니다.

 

2. 클라이언트 자격 증명 흐름(Client Credentials Flow)

클라이언트 자격 증명 흐름(Client Credentials Flow)은 OAuth 프로토콜에서 사용되는 인증 흐름 중 하나입니다. 이 흐름은 클라이언트 애플리케이션이 자체적으로 인증 제공자에게 액세스 토큰을 요청하는 방식입니다. 주로 서비스 간의 기계 간 통신에 사용됩니다. 다음은 클라이언트 자격 증명 흐름의 동작 방식입니다:
대칭 키 알고리즘은 암호가 있는 한 모든 것을 해독할 수 있는 암호화 알고리즘입니다.

1) 클라이언트 자격 증명 제공:

클라이언트 애플리케이션은 클라이언트 아이디와 클라이언트 시크릿(비밀 키)을 사용하여 인증 제공자에게 자격 증명을 제공합니다.

2) 액세스 토큰 요청:

클라이언트 애플리케이션은 클라이언트 자격 증명과 함께 액세스 토큰을 요청합니다.
인증 제공자는 클라이언트 아이디와 시크릿을 검증하고, 유효한 경우 액세스 토큰을 발급합니다.

3) 액세스 토큰 수신:

인증 제공자는 클라이언트 애플리케이션에게 액세스 토큰을 반환합니다.

클라이언트 애플리케이션은 이 액세스 토큰을 사용하여 보호된 리소스에 접근할 수 있습니다.
클라이언트 자격 증명 흐름은 클라이언트 애플리케이션이 자체적으로 인증을 처리하고, 사용자의 개입 없이 액세스 토큰을 얻을 수 있는 간편한 방법입니다. 이 흐름은 보통 서비스 간의 인증이 필요한 백그라운드 작업이나 API 호출 등에서 사용됩니다. 그러나 주의할 점은 클라이언트 자격 증명이 외부에 노출되지 않도록 적절한 보안 조치를 취해야 한다는 점입니다.

 

3. 인증 코드 흐름(Authorization Code Flow)

인증 코드 흐름(Authorization Code Flow)은 OAuth 프로토콜에서 사용되는 인증 흐름 중 하나입니다. 웹 애플리케이션에서 사용자의 인가 및 인증을 처리하는 과정으로, 다음과 같은 단계로 이루어집니다:

1) 사용자 리디렉션 및 동의
    사용자 요청을 인증 제공자를 통해 인증 동의 요청하고, 클라이언트에 대한 접근 권한을 요청 합니다.

2) 인가 코드 발급
    사용자가 동의하면, 인증 제공자는 인가 코드를 발급합니다

3) 인가 코드 교환
    클라이언트는 인증 제공자에게 액세스 토큰을 요청하고 인증 제공자는 인가 코드의 유효성을 검증하여, 클라이언트 애플리케이션에게 액세스 토큰과 함께 리프레시 토큰을 발급합니다.

4) 액세스 토큰 수신
    인증 제공자는 클라이언트 애플리케이션에게 액세스 토큰을 반환하고 클라이언트는 액세스 토근으로 리소스에 접근 합니다.

이 흐름은 클라이언트 애플리케이션이 사용자의 동의를 받고 인가 코드를 얻은 후, 이 코드를 사용하여 액세스 토큰을 얻는 방식입니다. 이를 통해 클라이언트 애플리케이션은 보호된 리소스에 대한 접근 권한을 얻을 수 있습니다. 인증 코드 흐름은 보안적으로 안전하고 일반적으로 웹 애플리케이션에서 사용됩니다.

 

4. Resource Owner Password Flow:

이 흐름은 클라이언트가 사용자의 사용자명과 비밀번호를 직접 수집하여 인증 제공자에게 전달하는 방식입니다.
클라이언트는 사용자의 자격 증명을 받아들이고, 액세스 토큰을 직접 요청합니다.
이 흐름은 보통 신뢰할 수 있는 클라이언트와 안전한 환경에서 사용됩니다. 다른 인증 흐름에 비해 보안적으로 더 취약할 수 있습니다.

 

5. Assertion Flow:

이 흐름은 클라이언트가 인증 제공자에게 사용자 인증 정보를 대신 제공하는 방식입니다.
클라이언트는 보안 토큰(예: SAML 주장)을 사용하여 사용자의 신원을 확인하고, 이를 인증 제공자에게 제출합니다.
인증 제공자는 이를 검증하고 액세스 토큰을 발급합니다.
이 흐름은 기업 환경에서 주로 사용되며, 다양한 인증 방법과 시스템 간에 통합을 가능하게 합니다.

 

6. Device Flow:

이 흐름은 입력 장치가 제한적인 장치(예: 스마트 TV, 게임 콘솔 등)에서 OAuth를 사용하는 경우에 사용됩니다.
장치는 액세스 토큰을 얻기 위해 사용자에게 인증 요청을 표시하고, 사용자는 다른 장치(예: 스마트폰 또는 컴퓨터)를 사용하여 토큰을 인증 제공자에게 요청합니다.
사용자는 장치에 표시된 인증 코드를 입력하여 인증을 완료합니다.
이 흐름은 사용자 경험을 향상시키고 입력 제약을 극복하기 위해 설계되었습니다.
이러한 인증 흐름은 클라이언트 애플리케이션의 요구 사항과 환경에 따라 선택됩니다. 각 흐름은 특정한 시나리오와 보안 요구에 적합한 방법을 제공합니다.

우리는 서로 다른 액터와 토큰 유형을 사용하여 6 개의 서로 다른 흐름을 다루었습니다. 클라이언트의 기능, 동의하는 클라이언트의 동의를 얻는 방법, OAuth에 많은 복잡성을 추가하는 방법 때문에 필요합니다.

사람들이 OAuth를 지원하는지 물어보면 그들이 무엇을 요구하는지 명확히 해야 합니다.6 개의 흐름을 모두 지원하는지 아니면 주요 흐름만 지원하는지 묻나요? 모든 다른 흐름 간에는 많은 세분 성을 사용할 수 있습니다.

 

 

참고

developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth