Nice programing

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

nicepro 2020. 10. 10. 11:01
반응형

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


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

의 OAuth 버전 2 스펙

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

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

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

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

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

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


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

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

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

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

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


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

참고 URL : https://stackoverflow.com/questions/6255104/oauth-v2-communication-between-authentication-and-resource-server

반응형