타사 OAuth 공급자를 통한 인증을 계속 허용하면서 OAuth로 REST API 보안 유지 (DotNetOpenAuth 사용)

웹 사용자 인터페이스를 사용하지 않고도 제품 사용자가 제품 기능과 직접 통합 할 수 있도록 간단한 REST API가있는 제품이 있습니다.

최근 저는 데스크톱 사용자를 API와 통합하여 제품 사용자가 해당 타사 응용 프로그램을 사용하여 데이터에 액세스 할 수 있도록 다양한 타사로부터 관심을 얻었습니다.

Twitter를 사용하려는 응용 프로그램은 Twitter에서 호스팅하는 로그인 페이지를 사용하여 인증하여 특정 응용 프로그램에 해당 사용자의 데이터에 액세스 할 수있는 권한을 부여합니다. "허용"또는 "거부"버튼을 클릭하면 인증 프로세스가 완료됩니다. 페이스 북은 내가 알 수있는 것과 같은 메커니즘을 사용합니다.

추가 연구 결과, 이것은 실제로 작동하는 것으로 보이며 내 API가 .Net 기반이기 때문에 DotNetOpenAuth를 사용하고 유사한 메커니즘을 제공해야한다고 생각합니다. 불행히도 샘플은 드물게 문서화되어 있으며 (필요한 경우) 온라인에서 찾을 수있는 유일한 자습서는 타사 제공 업체를 사용하여 웹 사이트에 로그인 할 수 있도록 사용자에게 로그인 메커니즘을 제공하는 데 중점을 둔 것으로 보입니다.

내가 정말로하고 싶은 것은 내 REST API가 내 웹 응용 프로그램의 모든 핵심 인증 및 비즈니스 논리를 처리하고 본질적으로 내 웹 응용 프로그램이 본질적으로 OAuth를 통해 API를 사용하는 다른 응용 프로그램이어야한다는 것입니다. 사용자는 사용자 이름과 비밀번호를 사용하거나 MyOpenID 또는 Facebook과 같은 타사 제공 업체를 통해 웹 사이트에서 직접 인증 한 다음 반환 된 토큰을 사용하여 REST API에 대해 인증합니다.

기본적으로 OAuth 서비스를 호스팅하기 위해 API가 필요하지만 사용자가 타사 OAuth 서비스를 사용하도록하는 것 같습니다. 도움이 될 수는 없지만 OAuth에 대한 이해가 부족하여 내가 너무 복잡하게하는지 또는 내가하려고하는 것이 일을하는 좋은 방법인지 나쁜지를 결정하는 데 충분하지 않다고 생각합니다.

누군가 내가 수행해야 할 단계에 대한 포괄적 인 개요를 제공 할 수 있습니까? 아니면 몇 가지 튜토리얼을 알려주시겠습니까? 아니면 내 제안을 폭로하고 (건축 적으로) 이것에 대해 내가 잘못 가고 있다고 말합니까?

먼저 인증과 권한 부여의 차이점을 강조하고 싶습니다.

사용자의 사용자 이름 + 암호와 같은 일부 자격 증명 등을 제공하여 웹 사이트에 인증합니다. OpenID는 사용자 가 다른 서비스를 인증 하도록 하여이를 대체 할 수 있으며 , 사용자를 대신하여 웹 사이트에 사용자의 신원을 부여합니다. 귀하의 사이트는 타사 서비스 (OpenID 공급자)를 신뢰하므로 사용자가 로그인 한 것으로 간주합니다.

서비스 또는 응용 프로그램은 웹 사이트에 인증하지 않습니다 - 적어도하지 일반적으로. 사용자 는 서비스 또는 애플리케이션이 사용자의 데이터에 액세스 할 수있는 권한을 부여 합니다. 이는 일반적으로 응용 프로그램이 서비스 공급자의 권한 부여를 요청한 다음 사용자를 서비스 공급자에게 보내면 사용자가 먼저 인증 한 다음 (서비스 공급자가 누구와 대화하는지 알 수 있음) 사용자가 사이트에 "예, [어플리케이션]이 내 데이터에 [제한된 방식으로] 액세스하는 것이 좋습니다 "". 그때부터 응용 프로그램은 인증 토큰을 사용합니다.서비스 제공 업체 사이트의 사용자 데이터에 액세스합니다. 응용 프로그램은 마치 사용자 인 것처럼 자체 인증하지는 않지만 다른 코드를 사용하여 서비스가 특정 사용자의 데이터에 액세스 할 수있는 권한이 있는지 확인합니다.

따라서 이러한 차이점을 명확히하여 사이트에서 인증 및 권한 부여에 대해 완전히 독립적으로 결정할 수 있습니다. 예를 들어, 사용자가 username + password, OpenID 및 Facebook 모두로 로그인 할 수있게하려면 그렇게 할 수 있습니다. 완전히 직교하는 결정은 응용 프로그램을 인증하는 방법입니다 (OAuth는 물론 널리 사용되는 많은 프로토콜이 있습니다).

OpenID는 사용자 인증에 중점을 둡니다 . OAuth는 응용 프로그램 인증에 중점을 둡니다 . 그러나 Facebook 및 Twitter와 같은 일부 서비스는 인증에 OpenID를 사용하고 인증에 OAuth를 사용하는 대신 인증 및 권한 부여에 OAuth를 사용하도록 선택했습니다 .

이제 자신의 프로젝트의 경우 VS Gallery에서 제공되는 ASP.NET MVC 2 OpenID 웹 사이트 (C #) 프로젝트 템플릿 을 확인하는 것이 좋습니다 . 기본적으로 OpenID 인증 및 OAuth 서비스 공급자 지원이 제공됩니다. 즉, 사용자는 OpenID로 로그인 할 수 있으며 타사 응용 프로그램 및 서비스는 OAuth를 사용하여 웹 사이트에 대한 API 호출을 수행하고 사용자 데이터에 액세스 할 수 있습니다.

일단이 프로젝트 템플릿에 추가하고 싶은 것처럼 보이는 것은 사용자가 OpenID뿐만 아니라 username + password로 로그인 할 수 있다는 것입니다. 또한 Facebook 및 Twitter를 사용자에게 옵션으로 사용하려면 OpenID 표준을 사용하지 않으므로이를 구현해야합니다. 그러나 DotNetOpenAuth 다운로드에는 Twitter 및 Facebook으로 로그인하기위한 샘플이 포함되어 있으므로 이에 대한 지침이 제공됩니다.

나는 당신이 인증 전선에서 할 일이별로 없을 것이라고 생각합니다. 내가 전에 말한 것처럼 OAuth와 함께 제공되며 아마도 당신에게 충분할 것입니다.

가장 먼저. 인증 방법과 API를 정신적으로 분리해야합니다.

API는 기본적으로 리소스이며 해당 리소스를 조작하는 방법입니다. 또한 API에 대한 액세스를 인증하는 몇 가지 방법을 사용할 수 있습니다.

OAuth는 그러한 인증 메커니즘 중 하나입니다. 사양이 이해하기 어렵지만 특히 서명과 관련된 부분이 있어도 OAuth 공급자는 훌륭합니다. OAuth를 설치하면 대부분의 언어로 사용할 수있는 "오픈 소스, 이미 구현 된 구현"라이브러리가 너무 많기 때문에 클라이언트 응용 프로그램은 일반적으로 인증하기가 쉽습니다.

OAuth의 장단점은 한동안 논의되었습니다. 그러나 OAuth 사양을 담당하는 사람들 중 하나 인 Eran Hammer-Lahav가 작성한이 명확한 가이드를 읽는 것이 좋습니다 .

내가 아는 한 OAuth의 유일한 대안은 OAuth 2.0과 단순한 기본 인증입니다.

그 외에 Open-ID 또는 페이스 북 ID 등을 사용하여 인증하는 것에 대해 이야기하고 있습니다. 이것은 또 다른 질문입니다. 그러나 실제로 API 및 OAuth 범위를 벗어납니다. 나에게, 그것은 당신의 서비스에서 사용자 생성에 대한 더 많은 질문을 느낍니다. 내가 틀렸을 수도 있습니다.