OAuth2 흐름-서버가 인증 서버로 유효성을 검사합니까?


10

나는 OAuth2에 대해 많은 것을 읽었으며 그 주위에 내 머리를 갖기 위해 노력하고 있지만 여전히 혼란 스럽습니다.

고객이 OAuth 제공 업체 (예 : Google)를 승인하고 리소스 서버가 사용자의 프로필 데이터에 액세스 할 수 있음을 이해합니다. 그러면 클라이언트는 액세스 토큰을 리소스 서버로 보내고 리소스를 다시받을 수 있습니다.

그러나 설명서에서 다루지 않은 것은 클라이언트 응용 프로그램이 리소스 서버에 리소스를 요청하고 액세스 토큰을 전달할 때 발생하는 것입니다. 지금까지 읽은 모든 내용은 리소스 서버가 요청 된 리소스로 응답한다고 말합니다.

그러나 그것은 거대한 구멍처럼 보입니다. 물론 리소스 서버는 어떻게 든 액세스 토큰의 유효성을 검사해야합니다. 그렇지 않으면 이전 요청을 위조하고 이전, 도난, 위조 또는 임의로 생성 된 토큰을 전달할 수 있습니다.

내가 읽은 것은 불완전하다고 느끼기 때문에 누구나 OAuth2에 대한 설명을 간단하게 지적 할 수 있습니까?

답변:


8

그것을 발견. 사양에 묻혔다. 그들은 리소스 서버가 인증 서버로 액세스 토큰의 유효성을 검사해야하지만 문서 범위를 벗어났다고 말합니다. 동정심, 토큰 검증이 중요한 부분이라고 생각했을 것입니다.


1
정보 중요한 부분 , 그것은 읽을 가치가있을 수도 있습니다 이 블로그 게시물 OAuth2를위한 우선 순위에 대한 몇 가지 배경을.
Lars Viklund

1
읽어 주셔서 감사합니다. iOS 앱이 Google, Twitter, Facebook 등으로 인증하고 일부 형식의 인증을 내 서버에 전달하고 서버에서 유효성을 검사하고 리소스에 액세스하도록 허용한다는 점에서 요구 사항이 다소 간단합니다. 이 문제가 어떻게 작동하고 어디에서 무엇을해야하는지 이해하는 복잡성 때문에 문제가 예상보다 복잡해졌습니다.
drekka

보다 정확하게는 부록 A : "요청시 서명의 유효성을 검사하기 위해 보호 된 리소스가 토큰 식별자를 권한 부여 서버의 내부 검사 엔드 포인트에 제출하여 해당 토큰에 필요한 주요 정보를 얻을 수 있습니다.이 사용법에 대한 자세한 내용은 외부에 있습니다. 이 규격의 범위는 확장자 [...] "로 정의 될 것이다.
JulienD

2

토큰 유효성 검사는 일반적으로 두 가지 방법 중 하나로 처리됩니다.

1) 토큰은 사전 공유 키를 사용하여 암호화되어 서명됩니다. 이것은 분산되고 확산되는 시스템에서 사용하기에 분명한 단점이 있습니다.

2) AS (Authorization Server)는 토큰 유효성 검증 또는 내부 검사를위한 엔드 포인트를 제공합니다. 이 방법은 2015 년 10 월 IETF RFC 7662에서 표준화되었습니다 ( https://tools.ietf.org/html/rfc7662 참조).

이 스택 오버플로 질문 / 답변에는 Google 및 Github의 예가 포함되어 있습니다. /programming/12296017/how-to-validate-an-oauth-2-0-access-token-for-a-resource-server


0

토큰의 유효성을 검사하는 방법에 대한 사양을 읽으십시오.

https://tools.ietf.org/html/rfc7662

이것이 도움이되기를 바랍니다-pls는 쿼리 / 문제에 대한 답변을 표시합니다.


4
소프트웨어 엔지니어링에 오신 것을 환영합니다. 현재 답변으로는이 답변이 Google의 품질 가이드 라인을 준수 하지 않습니다 . 답변은 독자적인 입장에 있어야합니다. 독자는 더 깊은 이해를 얻거나 출처를 확인하기 위해 외부 링크 만 따라야하며 관련 내용은 여기에 인용해야합니다.
Thomas Owens
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.