인증 및 권한 부여를 위한 OAuth 2.0 및 OIDC 기본 사항 [3부 중 1부]

개발자 및 아키텍트 권한 부여 및 인증 문제에 부딪히지 않고는 최신 애플리케이션을 구축할 수 없습니다.

OAuth 2.0 는 애플리케이션이나 클라이언트가 다른 앱이나 서비스에서 제공하는 데이터나 기능에 액세스할 수 있도록 하는 기능인 '위임 권한 부여'에 대한 업계 표준입니다. OAuth 2.0은 권한 부여에 중점을 두며 인증에 대한 규범적이지 않습니다. OpenID Connect(OIDC) 는 OAuth 2.0 위에 표준 기반 인증 계층을 추가합니다.

이를 맥락에 맞게 설명하면 다음과 같습니다, 카우치베이스 동기화 게이트웨이는 다양한 형태의 클라이언트 인증을 지원합니다.. 클라이언트 는 웹소켓 기반 웹소켓을 사용하여 인터넷을 통해 동기화 게이트웨이와 데이터를 동기화하는 Couchbase Lite 클라이언트일 수 있습니다. 복제 프로토콜를 통해 동기화 게이트웨이에 액세스하는 웹 프론트엔드 또는 모바일 앱일 수도 있습니다. 공용 REST 엔드포인트. 가장 널리 사용되는 Couchbase 동기화 게이트웨이 클라이언트 인증 메커니즘 중 하나는 OIDC입니다.

이 글에서는 인증 및 권한 부여를 위한 OAuth 2.0과 OIDC의 기본 사항을 다룹니다. 두 가지 일반적인 흐름, 즉 암시적 흐름 및 인증 코드 흐름. 흐름에 대한 기본적인 이해를 통해 동기화 게이트웨이 클라이언트 인증의 컨텍스트 내에서 OIDC 기반 인증을 사용하는 방법을 이해하는 데 충분한 배경 지식을 얻을 수 있을 것입니다. 이에 대한 자세한 내용은 향후 블로그 게시물에서 설명할 예정이니 기대해 주세요!

OIDC를 이해하려면 먼저 OAuth 2.0을 이해해야 합니다. 인증 프레임워크인 OIDC는 OAuth 2.0을 기반으로 구축되었기 때문입니다.

OAuth 2.0 입문서

OAuth 2.0 는 위임 권한에 대한 업계 표준이며, 다음과 같은 다양한 OAuth 공급자 를 출시했습니다.

예를 들어, 여러 웹 및 모바일 앱을 지원하는 'Facebook으로 로그인' 버튼을 생각해 보세요. 이 버튼은 OAuth 2.0을 사용하여 구현됩니다.

다음은 단순화 뒤에서 무슨 일이 벌어지는지 볼 수 있습니다. 아래에서는 아래에서 설명하는 것을 인증 코드 흐름. OIDC의 맥락에서 사용될 때 더 널리 사용되는 "암시적 흐름"이라는 대안도 있습니다.

전제 조건

먼저 앱/클라이언트를 권한 부여 서버에 등록해야 합니다. 등록 프로세스를 통해 client_id 및 클라이언트_비밀 를 설정한 다음 인증을 요청하는 앱/클라이언트에서 구성해야 합니다.

• • 사용자(일명, "리소스 소유자" )를 클릭한 후, OAuth 2.0 말하기에서 Facebook으로 로그인 버튼을 누르면 앱이 즐겨 찾는 앱에 권한 요청 를 인증 서버의 로그인 URL에 추가합니다. 이 예에서 인증 서버는 Facebook입니다. 권한 부여 요청에는 여러 매개변수가 포함됩니다. 간결성을 위해 전체 매개변수 목록은 여기에는 포함하지 않겠습니다. RFC6749. 요청에는 최소한 다음 매개 변수가 포함되어야 합니다:
    • client_id 앱을 권한 부여 서버에 고유하게 식별합니다.
    • 응답 유형 로 지정해야 합니다. 코드 클라이언트가 인증 코드를 기대한다는 것을 나타냅니다.
    • 요청_우리 인증 후 권한 부여 서버가 제어권을 리디렉션해야 하는 URL을 지정합니다.
  • 인증 서버(Facebook)는 사용자에게 사용자 이름과 비밀번호를 입력하고 (선택 사항으로) 사용자 인증에 필요한 여러 보안 질문에 답하라는 메시지를 표시합니다.
  • 인증이 완료되면 앱이 액세스하려는 Facebook 리소스 세트(예: 사용자의 공개 프로필)가 나열된 '리소스 동의 양식'이 사용자에게 표시됩니다(선택 사항).
    • 동의 양식에 제시된 리소스 집합은 다음을 통해 지정됩니다. 범위 매개 변수를 인증 서버에 초기 인증 요청에 전달합니다.
  • 사용자가 요청된 리소스에 대한 액세스를 승인하면 인증 코드가 있는 앱으로 다시 리디렉션됩니다.
    • 권한 부여 서버가 사용자를 리디렉션하는 URL은 다음을 통해 지정됩니다. redirect_uri 매개변수를 추가할 수 있으며, 이는 초기 권한 요청에도 포함됩니다.
  • 그런 다음 앱/클라이언트는 인증 서버와 인증 코드를 교환하여 불투명한 액세스 토큰 (또는 토큰 새로 고침)를 전달하여 client_id 그리고 클라이언트_비밀 요청의 일부로
  • 그러면 앱은 액세스 토큰을 사용하여 Facebook에서 요청된 리소스에 액세스할 수 있습니다.

혼란스러우신가요? 걱정하지 마세요. OIDC의 맥락에서 다시 한 번 살펴보겠습니다.

OIDC(OpenID Connect)란 무엇인가요?

OAuth 2.0의 주요 목표는 다음과 같습니다. 위임된 권한. 즉, 앞서 살펴본 것처럼 OAuth 2.0의 주요 목적은 앱에 다른 앱이 소유한 데이터에 대한 액세스 권한을 부여하는 것입니다.

OAuth 2.0은 인증에 중점을 두지 않으므로 OAuth 2.0을 사용한 인증 구현은 비표준입니다. 이것이 바로 OIDC(OpenID Connect)가 등장하는 이유입니다. OIDC는 OAuth 2.0 위에 표준 기반 인증 계층을 추가합니다.

이제 OAuth 2.0 플로우에서 권한 부여 서버는 다음과 같은 역할을 맡습니다. ID 서버 (또는 OIDC 공급자). 기본 프로토콜은 신원 서버가 다음을 제공한다는 점을 제외하면 OAuth 2.0과 거의 동일합니다. 신원 토큰 (ID 토큰)을 요청하는 앱에 전송합니다. ID 토큰은 사용자 인증에 대한 클레임을 인코딩하는 표준 방식입니다. 나중에 ID 토큰에 대해 자세히 설명하겠습니다.

여기에서는 널리 사용되는 두 가지 OIDC 플로우에 대해 설명하겠습니다: 암시적 흐름과 권한 부여 코드 흐름입니다.

전제 조건

이 두 가지 흐름 모두 앱/클라이언트를 권한 부여 서버에 등록해야 합니다. 등록 프로세스를 통해 client_id 및 클라이언트_비밀 를 설정한 다음 인증을 요청하는 앱/클라이언트에서 구성해야 합니다.

OIDC 암시적 흐름

OIDC 암시적 흐름 는 두 가지 중 더 간단하며 다음 블로그 게시물에서 자세히 설명할 동기화 게이트웨이와 함께 Couchbase Lite 클라이언트 인증에 사용하는 것이 좋습니다.

다시 한 번 Facebook으로 로그인 를 예로 들어 흐름을 설명합니다.

• • 사용자가 Facebook으로 로그인 버튼을 누르면 앱이 인증 서버 또는 ID 서버의 로그인 URL로 인증 요청을 보냅니다. 이 예에서 인증 서버는 Facebook입니다.
    • 인증 요청에는 여러 매개변수가 포함됩니다. 간결성을 위해 모든 매개변수의 전체 목록은 포함하지 않겠습니다. 는 OIDC 사양에서 찾을 수 있습니다.. 요청에는 최소한 다음 매개 변수가 포함되어야 합니다:
      • client_id 앱을 권한 부여 서버에 고유하게 식별합니다.
      • 응답 유형 로 지정해야 합니다. id_token 클라이언트가 ID 토큰을 기대한다는 것을 나타냅니다.
      • 범위 그 필수 에는 openid 범위 값과 앱이 액세스를 요청하는 리소스 목록(선택 사항)을 추가합니다.
      • 요청_우리 인증 후 권한 부여가 제어를 리디렉션해야 하는 URL을 지정합니다.
  • 그러면 신원 서버(Facebook)는 사용자에게 사용자 아이디와 비밀번호를 입력하고 (선택 사항으로) 사용자 인증에 필요한 여러 보안 질문에 답하라는 메시지를 표시합니다.
  • 인증이 완료되면 앱이 액세스하려는 Facebook 리소스 세트(예: 사용자의 공개 프로필)가 나열된 '리소스 동의 양식'이 사용자에게 표시됩니다(선택 사항).
    • 동의 양식에 제시된 리소스 세트는 다음을 통해 지정됩니다. 범위 매개변수는 인증 서버에 대한 초기 인증 요청에 포함되었습니다.
  • 사용자가 요청된 리소스에 대한 액세스를 승인하면 사용자는 앱으로 다시 리디렉션됩니다. 신원 토큰 그리고 선택적으로 액세스 토큰
    • 인증 서버가 사용자를 리디렉션하는 URL은 다음을 통해 지정됩니다. redirect_uri 매개변수를 추가할 수 있으며, 이는 초기 인증 요청에도 포함됩니다.
  • 그런 다음 앱은 지정된 기준에 따라 신원 토큰의 유효성을 검사합니다. OIDC 사양 를 호출하여 인증된 사용자의 신원을 검색합니다.

OIDC 인증 코드 흐름

OIDC 인증 코드 흐름 는 앞서 설명한 OAuth 2.0 인증 코드 흐름과 매우 유사합니다.

다시 한 번 Facebook으로 로그인 를 예로 들어 흐름을 설명합니다.

• • 사용자가 Facebook으로 로그인 버튼을 누르면 앱이 인증 서버 또는 ID 서버의 로그인 URL로 인증 요청을 보냅니다. 이 예제에서 인증 서버는 Facebook입니다.
    • 인증 요청에는 여러 매개변수가 포함됩니다. 간결성을 위해 모든 매개변수의 전체 목록은 여기에는 포함하지 않겠습니다. OIDC 사양. 요청에는 최소한 다음 매개 변수가 포함되어야 합니다:
      • client_id 앱을 권한 부여 서버에 고유하게 식별합니다.
      • 응답 유형 로 지정해야 합니다. 코드 클라이언트가 인증 코드를 기대한다는 것을 나타냅니다.
      • 범위 그 필수 에는 openid 범위 값과 앱이 액세스를 요청하는 리소스 목록(선택 사항)을 추가합니다.
      • 요청_우리 인증 후 권한 부여가 제어를 리디렉션해야 하는 URL을 지정합니다.
  • 그러면 신원 서버(Facebook)는 사용자에게 사용자 아이디와 비밀번호를 입력하고 (선택 사항으로) 사용자 인증에 필요한 여러 보안 질문에 답하라는 메시지를 표시합니다.
  • 인증이 완료되면 앱이 액세스하려는 Facebook 리소스 세트(예: 사용자의 공개 프로필)가 나열된 '리소스 동의 양식'이 사용자에게 표시됩니다(선택 사항).
    • 동의 양식에 제시된 리소스 세트는 다음을 통해 지정됩니다. 범위 매개변수를 추가할 수 있으며, 이는 인증 서버에 대한 초기 인증 요청에도 포함됩니다.
  • 사용자가 요청된 리소스에 대한 액세스를 승인하면 사용자는 앱으로 다시 리디렉션됩니다. 인증 코드
    • 권한 부여 서버가 사용자를 리디렉션하는 URL은 다음을 통해 지정됩니다. redirect_uri 매개변수를 추가할 수 있으며, 이는 초기 권한 요청에도 포함됩니다.
  • 그런 다음 앱/클라이언트는 인증 서버와 인증 코드를 교환합니다. 신원 토큰 와 불투명한 액세스 토큰을 전달하여 client_id 그리고 클라이언트_비밀 요청의 일부로
  • 그런 다음 앱은 지정된 기준에 따라 신원 토큰의 유효성을 검사합니다. OIDC 사양 를 호출하여 인증된 사용자의 신원을 검색합니다.

JSON 웹 토큰(JWT)

OIDC의 핵심 요소는 사용자에 대한 인증 클레임을 표준 형식으로 인코딩하는 보안 토큰인 신원 토큰입니다. JSON 웹 토큰(JWT). JWT는 디지털 서명이 되어 있습니다.

"클레임"은 사용자에 대한 주장입니다. 다음은 일반적인 클레임 집합이 있는 JWT의 예입니다.

• • sub 는 JWT가 참조하는 사용자입니다.
  • iss 는 JWT 발급자이며 JWT에 서명합니다.
  • aud 토큰의 대상은 다음과 같습니다.
  • iat 는 발행된 타임스탬프입니다.
  • exp 는 만료 타임스탬프입니다.
  • amr 토큰을 발급하는 데 사용되는 인증 방법을 나타냅니다.

추가 리소스

jwt.io 는 JWT를 디코딩하고 확인하는 데 매우 유용합니다.

그리고 OIDC 및 OAuth 놀이터 는 실제로 구현하지 않고도 흐름을 시험해 볼 수 있는 훌륭한 리소스입니다.

다음 단계

이 게시물에서는 OIDC(OpenID Connect)와 OAuth 2.0 흐름의 기본 사항에 대해 설명했습니다. 다음 주 게시물에서는 동기화 게이트웨이 클라이언트 인증의 맥락에서 OIDC 기반 인증에 대해 설명하겠습니다. 기대해주세요!

질문이나 피드백이 있으시면 아래에 댓글을 남기거나 이메일을 보내주세요. priya.rajagopal@couchbase.com. . 카우치베이스 포럼 를 통해 질문할 수 있습니다.
 

인증 및 권한 부여에 관한 이 시리즈의 나머지 포스팅도 놓치지 마세요: