인증과 리소스 서버 간의 OAuth v2 통신

OAUTH-v2의 작동 방식을 이해하는 데 문제가 있습니다.

의 OAuth 버전 2 사양 읽

7. 보호 된 리소스에 액세스

   클라이언트는
   리소스 서버에 액세스 토큰을 제공하여 보호 된 리소스에 액세스 합니다. 리소스 서버는
   액세스 토큰의 유효성을 검사하고 만료되지 않았는지 그리고 해당 범위
   가 요청 된 리소스를 포함하는지 확인해야 합니다. 리소스 서버가
   액세스 토큰 (및 오류 응답)의 유효성 을 검사하는 데 사용하는 방법 은이 사양의 범위를 벗어나지 만 일반적으로 리소스 서버와 권한 부여
   서버 간의 상호 작용 또는 조정을 포함 합니다 .

리소스 서버와 권한 서버 간의 이러한 상호 작용은 실제로 어떻게 작동합니까?

• 리소스 서버는 수신 한 액세스 토큰이 유효한지 어떻게 결정합니까?
• 리소스 서버는 특정 리소스에 대한 액세스 권한을 부여해야하는지 확인하기 위해 토큰에서 허용 된 범위를 어떻게 추출합니까? 범위가 액세스 토큰에 인코딩되어 있습니까? 아니면 리소스 서버가 먼저 권한 부여 서버에 연결해야합니까?
• 리소스 서버와 권한 서버 간의 신뢰는 어떻게 설정됩니까?

보호 된 리소스에 액세스하는 데 사용되는 액세스 토큰 속성 및 방법 은이 사양의 범위를 벗어나며 동반 사양에 의해 정의됩니다.

누군가 토큰 속성에 대한 예제를 줄 수 있습니까?

이것이 사양의 범위를 벗어난 이유는 두 엔터티 간의 이러한 연결을 수행하는 광범위한 방법 때문입니다. 주요 질문은 배포가 얼마나 복잡한 지입니다.

예를 들어 인증 및 액세스를 관리하는 서버 하나와 API 호출을 제공하는 자체 서버가있는 개별 서비스 집합이 있습니까? 또는 인증 / 승인 및 API 호출을 모두 처리하는 하나의 웹 서버가있는 상자가 하나뿐입니까?

단일 박스의 경우 토큰을 발행하는 주체가이를 검증하는 주체와 동일하므로 많이 필요하지 않습니다. 토큰을 구현하여 데이터베이스 테이블 키를 사용하고 모든 요청에서 데이터베이스 (또는 메모리 캐시)의 레코드를 조회하거나 범위, 사용자 ID 및 기타 정보를 토큰에 직접 인코딩하고 대칭 또는 비대칭을 사용하여 암호화 할 수 있습니다. 연산.

분산 환경을 다룰 때 상황이 조금 더 복잡해 지지만 그다지 많지는 않습니다. 권한 부여 서버에서 여전히 토큰을 발행하지만 리소스 서버는이를 검증 할 방법이 필요합니다. 리소스 서버에서 내부 API를 사용하여 권한 부여 서버에 토큰 (로컬 환경에서 빠를 수 있음)을 "해결"하도록 요청하거나 두 사람이 공개 / 개인 키 쌍 또는 대칭 비밀을 설정할 수 있습니다. 이를 사용하여 리소스 서버에 필요한 모든 것을 토큰으로 암호화합니다.

자체 포함 된 토큰은 더 길지만 요청 당 훨씬 더 나은 성능을 제공합니다. 그러나 가격과 함께 제공됩니다. 유효 기간 (만료되지 않음) 동안에는 실제로 취소 할 수 없습니다. 이러한 이유로 자체 포함 된 토큰은 매우 짧아야합니다 (액세스 권한이 취소 된 후 열어 두는 것이 허용되는 모든 것 (예 : 많은 사이트에서 1 시간 사용)). 새 토큰을 얻기 위해 1 년 이상 사용할 수있는 새로 고침 토큰이 있어야합니다.

리소스-인증 서버 API의 한 예는 Google 개발자 웹 사이트에있는 것 입니다.
그러나 액세스 토큰의 형식을 지정하지는 않지만 응답은 보편적으로 유용합니다.