🥇OAuth 및 OpenID Connect에 대한 그림 가이드

메모. 번역: Okta의 이 훌륭한 기사는 OAuth 및 OIDC(OpenID Connect)가 작동하는 방식을 간단하고 명확하게 설명합니다. 이 지식은 개발자, 시스템 관리자, 심지어 다른 서비스와 기밀 데이터를 교환할 가능성이 가장 높은 인기 있는 웹 애플리케이션의 "일반 사용자"에게도 유용할 것입니다.

인터넷 석기시대에는 서비스 간 정보 공유가 쉬웠다. 한 서비스에서 다른 서비스로 로그인과 암호를 제공하기만 하면 그가 귀하의 계정에 들어가 필요한 정보를 받을 수 있습니다.

"은행계좌를 주세요." “비밀번호와 돈만 있으면 모든 것이 잘 될 것을 약속드립니다. 정직하다, 정직하다!" *히히*

공포! 어느 누구도 사용자에게 사용자 이름과 암호를 공유하도록 요구해서는 안 됩니다. 신임장, 다른 서비스와 함께. 이 서비스를 제공하는 조직이 데이터를 안전하게 유지하고 필요 이상의 개인 정보를 수집하지 않는다는 보장은 없습니다. 이상하게 들릴지 모르지만 일부 앱은 여전히 이 방법을 사용합니다!

오늘날 하나의 서비스가 다른 서비스의 데이터를 안전하게 사용할 수 있도록 하는 단일 표준이 있습니다. 불행하게도 그러한 표준은 많은 전문 용어와 용어를 사용하여 이해를 복잡하게 만듭니다. 이 자료의 목적은 간단한 삽화를 사용하여 작동 방식을 설명하는 것입니다(제 그림이 아이들의 칠하기와 비슷하다고 생각하십니까? 오 그렇군요!).

그런데 이 가이드는 비디오 형식으로도 제공됩니다.

신사 숙녀 여러분 환영합니다: OAuth 2.0

OAuth 2.0 한 응용 프로그램이 다른 응용 프로그램의 정보에 액세스할 수 있는 권한을 얻을 수 있도록 하는 보안 표준입니다. 허가증 발급 단계 순서 [허가] (또는 동의하다 [동의]) 자주 전화 권한 부여 [권한 부여] 또는 위임된 승인 [위임된 권한]. 이 표준을 사용하면 응용 프로그램이 암호를 제공하지 않고도 데이터를 읽거나 다른 응용 프로그램의 기능을 대신 사용할 수 있습니다. 수업!

예를 들어 "Unlucky Pun of the Day"라는 사이트를 발견했다고 가정해 보겠습니다. [오늘의 끔찍한 말장난] 전화로 문자 메시지 형태로 매일 말장난을 받기 위해 등록하기로 결정했습니다. 사이트가 정말 마음에 들었고 모든 친구들과 공유하기로 결정했습니다. 결국, 모두가 소름 끼치는 말장난을 좋아합니다, 그렇죠?

“오늘의 불행한 말장난: 왼쪽 반신을 잃은 사람에 대해 들었어? 이제 그는 항상 옳습니다!” (대략적인 번역, 원본에는 고유한 말장난이 있기 때문에 대략적인 번역입니다.)

연락처 목록에서 각 사람에게 편지를 쓰는 것은 선택 사항이 아님이 분명합니다. 그리고 당신이 나와 조금이라도 같다면 불필요한 일을 피하기 위해 무슨 짓이든 할 것입니다. 다행스럽게도 오늘의 끔찍한 말장난은 혼자서 모든 친구들을 초대할 수 있습니다! 이렇게 하려면 연락처의 이메일에 대한 액세스를 열면 됩니다. 사이트 자체에서 초대장을 보냅니다(OAuth 규칙)!

“모두 말장난을 좋아합니다! - 이미 로그인하셨습니까? “Terrible Pun of the Day 웹 사이트에서 연락처 목록에 액세스하도록 허용하시겠습니까? - 감사합니다! 지금부터 우리는 시간이 끝날 때까지 당신이 아는 모든 사람에게 매일 알림을 보낼 것입니다! 당신은 최고의 친구입니다!"

이메일 서비스를 선택하세요.
필요한 경우 메일 사이트로 이동하여 계정에 로그인합니다.
끔찍한 말장난에 연락처에 액세스할 수 있는 권한을 부여하세요.
오늘의 끔찍한 말장난 사이트로 돌아갑니다.

마음이 바뀔 경우를 대비하여 OAuth를 사용하는 애플리케이션은 액세스 권한을 취소할 수 있는 방법도 제공합니다. 더 이상 오늘의 끔찍한 말장난과 연락처를 공유하지 않기로 결정하면 메일 사이트로 이동하여 승인된 응용 프로그램 목록에서 말장난 사이트를 제거할 수 있습니다.

OAuth 흐름

우리는 일반적으로 불리는 것을 방금 통과했습니다. 흐름 [흐름] OAuth. 이 예에서 이 흐름은 두 서비스가 안전한 정보 교환에 동의하는 몇 가지 보이지 않는 단계뿐만 아니라 보이는 단계로 구성됩니다. 이전의 끔찍한 말장난 예는 "권한 부여 코드" 흐름으로 알려진 가장 일반적인 OAuth 2.0 흐름을 사용합니다. ["인증 코드" 흐름].

OAuth 작동 방식에 대해 자세히 알아보기 전에 몇 가지 용어의 의미에 대해 이야기해 보겠습니다.

리소스 소유자:

그건 너다! 귀하는 귀하의 자격 증명과 데이터를 소유하고 귀하의 계정에서 수행될 수 있는 모든 활동을 제어합니다.
Client:

사용자를 대신하여 특정 작업에 액세스하거나 수행하려는 애플리케이션(예: 오늘의 끔찍한 말장난 서비스) 리소스 소유자'아.
인증 서버:

아는 앱 리소스 소유자'a 그리고 u 리소스 소유자이미 계정이 있습니다.
리소스 서버:

애플리케이션 프로그래밍 인터페이스(API) 또는 서비스 Client 대신 사용하고자 리소스 소유자'아.
리디렉션 URI:

그 링크 인증 서버 리디렉션합니다 리소스 소유자' 권한을 부여한 후 Client'에. "콜백 URL"이라고도 합니다.
응답 유형:

받을 것으로 예상되는 정보의 유형 Client. 가장 일반적인 응답 유형'옴은 코드입니다. Client 받을 것으로 기대한다 인증 코드.
범위:

필요한 권한에 대한 자세한 설명입니다. Client데이터 액세스 또는 특정 작업 수행과 같은 'y.
동의:

인증 서버 걸린다 범위요청 Client옴, 그리고 묻는다 리소스 소유자'a, 그가 제공할 준비가 되었습니까? Client'적절한 권한이 있습니다.
고객 ID:

이 ID는 식별하는 데 사용됩니다. Client에 인증 서버'이자형.
고객 비밀:

본인만 아는 비밀번호입니다 Client너와 인증 서버'에. 비공개로 정보를 공유할 수 있습니다.
인증 코드:

유효 기간이 짧은 임시 코드로, Client 제공 인증 서버대신에 액세스 토큰.
액세스 토큰:

클라이언트가 통신에 사용할 키 리소스 서버옴. 제공하는 일종의 배지 또는 키 카드 Client'데이터를 요청하거나 작업을 수행할 권한이 있습니다. 리소스 서버당신을 대신해.

주의: Authorization Server와 Resource Server가 동일한 서버인 경우가 있습니다. 그러나 경우에 따라 동일한 조직에 속하지 않더라도 서로 다른 서버일 수 있습니다. 예를 들어 권한 부여 서버는 리소스 서버가 신뢰하는 타사 서비스일 수 있습니다.

이제 OAuth 2.0의 핵심 개념을 다루었으므로 예제로 돌아가 OAuth 흐름에서 어떤 일이 발생하는지 자세히 살펴보겠습니다.

당신, 리소스 소유자, 오늘의 끔찍한 말장난 서비스(Clienty) 모든 친구에게 초대장을 보낼 수 있도록 연락처에 액세스합니다.
Client 브라우저를 페이지로 리디렉션 인증 서버'a 및 쿼리에 포함 고객 ID, 리디렉션 URI, 응답 유형 그리고 하나 이상 범위 (권한) 필요합니다.
인증 서버 필요한 경우 사용자 이름과 암호를 요청하여 사용자를 확인합니다.
인증 서버 양식을 표시합니다 동의 (확인) 모두의 목록 첨부 범위요청 Client옴. 당신은 동의하거나 거절합니다.
인증 서버 사이트로 리디렉션합니다. Client', 사용 리디렉션 URI 함께 인증 코드 (인증 코드).
Client 와 직접 소통하다 인증 서버'옴(브라우저 우회 리소스 소유자'a) 그리고 안전하게 보낸다 고객 ID, 고객 비밀 и 인증 코드.
인증 서버 데이터를 확인하고 응답 액세스 토큰'om(액세스 토큰).
지금 Client 사용할 수 있습니다 액세스 토큰 ~에게 요청을 보내다 리소스 서버 연락처 목록을 가져옵니다.

클라이언트 ID 및 비밀

오늘의 끔찍한 말장난이 연락처에 액세스하도록 허용하기 오래 전에 클라이언트와 권한 부여 서버는 작업 관계를 설정했습니다. 인가 서버는 클라이언트 ID와 클라이언트 시크릿(종종 호출됨)을 생성했습니다. 앱 ID и 앱 비밀) OAuth 내에서 추가 상호 작용을 위해 클라이언트에 전송했습니다.

"- 안녕하세요! 나는 당신과 함께 일하고 싶습니다! - 네, 문제 없습니다! 여기 클라이언트 ID와 비밀이 있습니다!”

이름은 Client Secret이 Client와 Authorization Server만 알 수 있도록 비밀로 유지되어야 함을 암시합니다. 결국 Authorization Server가 클라이언트의 진실을 확인하는 것은 그의 도움입니다.

하지만 그게 다가 아닙니다... OpenID Connect를 환영해주세요!

OAuth 2.0은 권한 부여 - 한 응용 프로그램에서 다른 응용 프로그램으로 데이터 및 기능에 대한 액세스를 제공합니다. OpenID Connect (OIDC)는 계정에 로그인한 사용자의 로그인 및 프로필 세부 정보를 추가하는 OAuth 2.0 위에 얇은 레이어입니다. 로그인 세션의 구성은 종종 다음과 같이 불립니다. 입증 [입증], 시스템에 로그인한 사용자에 대한 정보(예: 리소스 소유자'e), — 개인 정보 [신원]. 인가 서버가 OIDC를 지원하는 경우 이를 개인정보 제공자 [ID 제공자]제공하기 때문에 Client'에 대한 정보를 가지고 리소스 소유자'이자형.

OpenID Connect를 사용하면 여러 애플리케이션에서 단일 로그인을 사용할 수 있는 시나리오를 구현할 수 있습니다. 싱글 사인온 (SSO). 예를 들어 애플리케이션은 Facebook 또는 Twitter와 같은 소셜 네트워크와의 SSO 통합을 지원하여 사용자가 이미 가지고 있고 선호하는 계정을 사용할 수 있도록 합니다.

흐름(flow) OpenID Connect는 OAuth의 경우와 동일하게 보입니다. 유일한 차이점은 기본 요청에서 사용되는 특정 범위가 openid, - ㅏ Client 결국 같아진다 액세스 토큰과 ID 토큰.

OAuth 흐름과 마찬가지로 액세스 토큰 OpenID Connect에서 이것은 명확하지 않은 값입니다. Client'에. 관점에서 Client'아 액세스 토큰 각 요청과 함께 전달되는 문자열을 나타냅니다. 리소스 서버'y, 토큰이 유효한지 결정합니다. ID 토큰 완전히 다른 것을 나타냅니다.

ID 토큰은 JWT입니다.

ID 토큰 JSON 웹 토큰 또는 JWT로 알려진 특수 형식의 문자열입니다. (종종 JWT 토큰은 "jots"처럼 발음됩니다.). 외부 관찰자에게는 JWT가 이해할 수 없는 횡설수설처럼 보일 수 있지만 Client JWT에서 ID, 사용자 이름, 로그인 시간, 만료 날짜와 같은 다양한 정보를 추출할 수 있습니다. ID 토큰'a, JWT를 방해하려는 시도의 존재. 데이터 내부 ID 토큰'라고 부른다 애플리케이션 [주장].

OIDC의 경우 표준 방식도 있습니다. Client 개인에 대한 추가 정보를 요청할 수 있습니다. [신원] 부터 인증 서버예를 들어 다음을 사용하는 이메일 주소 액세스 토큰.

OAuth 및 OIDC에 대해 자세히 알아보기

그래서 OAuth와 OIDC가 어떻게 작동하는지 간략하게 살펴보았습니다. 더 깊이 파고들 준비가 되셨나요? 다음은 OAuth 2.0 및 OpenID Connect에 대해 자세히 알아보는 데 도움이 되는 추가 리소스입니다.

언제나 그렇듯이 자유롭게 의견을 말하십시오. 최신 뉴스를 최신 상태로 유지하려면 구독하십시오. 트위터 и 유튜브 개발자를 위한 Okta!

번역가의 추신

블로그에서도 읽어보세요.

출처 : habr.com

OAuth 및 OpenID Connect에 대한 그림 가이드