인증을 위해 타사 (예 : Google, Facebook, Twitter)를 사용하려면 RESTful 웹 서비스를 어떻게 설계해야합니까?

내 직업을 위해 우리는 멋진 RESTful 웹 서비스를 보유하고 있으며 우리가 보유한 몇 개의 웹 사이트를 구동하는 데 사용했습니다. 기본적으로 웹 서비스를 사용하면 지원 티켓을 만들고 사용할 수 있으며 웹 사이트는 프런트 엔드를 담당합니다. 모든 웹 서비스 요청은 인증 헤더를 사용하여 각 호출에 대해 사용자 및 비밀번호의 유효성을 검사합니다.

올해 우리는 웹 사이트 사용자가 Google, Twitter 및 Facebook (아마도 다른 사람)을 통해 로그인 할 수 있도록 로그인 옵션을 확장하려고합니다. 그러나 웹 서비스가 타사 인증 공급자를 사용하여 사용자가 자신이 누구인지 확인하기 위해이를 설계하는 방법을 알아내는 데 많은 어려움이 있습니다. 이 작업을 수행하는 방법에 대한 모범 사례가 있습니까?

현재 웹 사이트에서 사용자 인증을 처리하고 웹 서비스 백엔드에 현재 세션을 등록하는 새로운 setSessionId 호출을 사용하려고합니다. 웹 서비스에 대한 각 추가 요청은 해당 sessionId를 통과하고 유효성을 검사합니다. 이것들은 괜찮아 보이지만, 나는 이것을 생각하지 않고 내 포럼 뒤에서 모든 포럼을 탐색하고 oauth 및 openid 사양을 읽는 것이 더 혼란 스럽다는 느낌이 들었습니다. 이 문제를 해결하는 방법에 대한 팁이 있습니까?

두 가지 목표가있는 것 같습니다.

1. 최종 사용자가 기존 소셜 계정으로 쉽게 인증 할 수 있습니다.
2. 웹 서비스를 사용하는 개발자가 쉬움

사람들이 사이트에서 리소스를 사용할 수 있도록 권한을 부여하면 클라이언트 라이브러리의 인기와 가용성으로 인해 OAuth2가 선호되는 메커니즘입니다.

1. 최종 사용자가 기존 소셜 계정으로 쉽게 인증 할 수 있습니다.

최종 사용자는 API를 사용하는 사이트를 방문하고 로그인을 선택합니다. OAuth 로그인 페이지로 전송됩니다. 로그인 페이지에는 사이트에서 관리되는 계정에 대한 일반 사용자 이름 및 비밀번호 프롬프트와 Facebook과 같은 사이트를 통해 클릭하여 로그인 할 수있는 소셜 인증 버튼 세트가 표시됩니다. 사용자가 Facebook을 선택하면 Facebook으로 리디렉션하여 선택을 승인합니다 (Facebook 인증 흐름 시작). 최종 사용자가 Facebook에서 로그인을 완료하면 사이트로 다시 리디렉션됩니다.

사용자가 Facebook에서 사이트로 다시 리디렉션되면 해당 사용자 정보를 데이터베이스의 사용자 레코드에 저장 한 다음 해당 사용자에 대한 새 세션을 생성합니다. oauth access_token을 사용하여 최종 사용자를 원래 다운 스트림 사이트로 즉시 리디렉션하여 원래 oauth 흐름을 완료합니다.

2. 웹 서비스를 사용하는 개발자가 쉽게

권한 부여 제공자 인 경우 oauth를 완벽하게 구현하지 않는 새로운 업스트림 인증 제공자를 추가 할 때마다 개발자가 변경하지 않는 간단한 인터페이스를 작성해야합니다. 그렇기 때문에 OAuth2 제공 업체 사이트를 구현해야하며 해당 사이트는 소셜 인증 사이트의 소비자 여야합니다.

멋진 휴식 API를 사용하는 개발자에게는 세션 캡처 게시물을 통해 힌트를 제공하지 않으면 Facebook 상호 작용을 알 수 없습니다 (예 :).

TL; DR

OAuth2를 구현하고 소셜 인증 복잡성을 숨겨 API 소비자를 귀하와 같은 소비자로 만드십시오. 다운 스트림 사이트에 대한 oauth 흐름 중에 페이스 북을 사용하여 추가 oauth 흐름을 트리거 할 수 있습니다.

그림 == 단어 * 1000이므로 이미지 :

이것을 oauth2-piggy-back이라고 부를 수 있습니까?

단계별 흐름

1. 최종 사용자가 귀하의 API를 사용하는 사이트를 방문합니다
2. 최종 사용자가 승인 또는 가입을 위해 사이트로 전송됩니다 (oauth2)
3. 최종 사용자가 소셜 인증을 선택하고 페이스 북 로그인 버튼을 클릭
4. 귀하의 사이트는 쿠키를 설정하거나 state페이스 북 oauth에서 사용자가 어디에서 왔는지 알 수 있도록 설정합니다
5. 최종 사용자가 Facebook으로 리디렉션되고 페이스 북 사이트에서 연결을 수락 함
6. 최종 사용자가 사이트로 리디렉션되어 페이스 북 인증 프로세스 완료
7. 데이터베이스에서 사용자를 조회하거나 작성합니다.
8. 서버에서 새 세션을 만듭니다
9. 세션 토큰을 사용하여 사용자를 원래 사이트로 다시 리디렉션합니다.

확장 가능하게 만드는 방법

먼저이 모든 API가 로그인에 동일한 메커니즘을 사용한다는 것을 알아야합니다. 모두 인증에 OAuth를 사용합니다. 이를 위해서는 일반 OAuth 라이브러리로 시작하여 활용해야합니다. 인증을 위해 자체 라이브러리를 사용하지 마십시오. 다른 공급자는 사용할 수 없습니다. OAuth2가 중단되면 공급자를 더 쉽게 추가 할 수 있습니다.

트위터는 여전히 OAuth2 악 대차를 뛰어 넘지 않았기 때문에 불행히도 두 가지가 필요합니다.

OAuth는 인증 당사자에 대한 인터페이스를 작성해야합니다. 토큰은 서버에서 서버로 교환됩니다. 모든 통신을 처리 할 수있는 하나의 진입 점을 만듭니다.

토큰은 계정과 별도의 테이블에 저장해야합니다. 이는 여러 개의 토큰과 여러 개의 연결된 프로필 일 수 있기 때문입니다. 일부 서비스는 두 개의 토큰을 제공하며 그 중 하나는 새로 고침 토큰입니다.

이제 필요한 다른 기능을 캡슐화하는 인터페이스를 설계하십시오. 개인적으로 별도의 REST 서비스를 설정하려고합니다. 이런 식으로 인증을 다른 곳으로 쉽게 확장 할 수 있습니다.
일부 서비스는 JSON을 사용하여 통신하고, 다른 서비스는 XML 등을 사용합니다. 초기 사용자의 경우 모두 통합해야합니다. 이것은 매우 고통스러운 과정이지만 여기에서 몇 가지 일반적인 근거를 도출 할 수 있습니다.

여기서 또 다른 문제는 모든 서비스가 동일한 기능을 제공하지는 않는다는 것입니다. 이는 서비스가 지정한대로 전체 API를 제공 할 수 없음을 의미 할 수 있습니다. 여기에는 응용 프로그램을 정상적으로 다운 그레이드 할 수있는 전략이 필요합니다.

이를 통해 새로운 타사 제공 업체를 쉽게 추가 할 수 있습니다.

토큰 문제

토큰은 시간이 제한되어 있으므로 토큰을 계속 사용할 수 있는지 확인하는 두 개의 cron 작업이 필요합니다. 그렇지 않으면 토큰을 삭제해야합니다. 이 메커니즘으로 토큰을 새로 고칠 수도 있습니다.

때때로 사용자가 토큰을 취소합니다. 준비하십시오.

정보 저장소

이 디자인을 가지고 있다면 필요한 데이터에 대해 생각해야합니다. 이것은 방금 생성 한 인터페이스의 일부입니다. 이를 위해 일부 테이블을 디자인하고 실제로 데이터를 검색 할 수 있는지 확인하십시오. 일부 서비스에서는 많은 데이터를 얻을 수 없습니다. 필요한 데이터가 많을수록 개인 정보 보호 메시지가 더 많이 필요하다는 점도 고려해야합니다. 따라서 필요에 따라 겸손하지 않으면 사용자가 사용하지 않습니다.

추가 확인을 위해 프로파일을 사용자와 별도의 링크 된 테이블에 저장할 수 있습니다. 이것은 누군가에게 더 많은 정보를 제공 할 것입니다.

또한 추가주의가 필요한 일부 데이터에 대해서는 현지 법률을 확인하십시오.

마지막으로 자신의 서비스에 계정을 만들지 않는 경우 잘못을 저 지르지 마십시오. 사용자가 페이스 북에서 금지 된 경우, 효과적으로 서비스에 로그인 할 수 없습니다. 이것은 당신이 만들고 싶지 않은 상황입니다. 이것은 종종 간과됩니다.

클라이언트 측 웹 사이트에서 타사 인증을 구현 한 다음 해당 타사 인증 토큰을 웹 사이트 사용자 계정과 연결 한 다음 setSessionID 호출을 트리거합니다. 로그인.

웹 사이트 아키텍처에 따라 EveryAuth 또는 Passport 와 같은 라이브러리를 사용하면 매우 유용 할 수 있습니다.

내 두 센트 : 나는 전에 이와 같은 일을 한 적이 없으며 FB, Twitter 또는 Google 로그인 메커니즘이 어떻게 작동하는지 알지 못하지만 질문을 읽 자마자 몇 가지 문제가 내 머리에 나타납니다.

• 다중 로그인 : 언젠가 내 Facebook 계정으로 로그인하고 다음 날 Google 계정으로 로그인하면 어떻게됩니까? 아니면 동시에? 이 두 계정을 고유 한 별도의 계정으로 취급합니까, 아니면 두 계정을 연결하여 어느 방식 으로든 티켓에 액세스 할 수있는 방법이 있습니까?
• 외부 식별자에 의존 : Facebook 또는 Twitter가 계정 식별자의 모양을 변경하기로 결정하면 어떻게됩니까? 예를 들어, BazLogin이 코드 {4382-af56}을 사용하여 고유 한 계정을 나타내지 만 8 개가 충분하지 않아서 지금부터 계정에 12 자리가 있다고 결정하면 {0000-4382에서 {1234-4382-af56}에게 -af56}?

세션 ID뿐만 아니라 외부 계정을 내부 계정과 연결하도록 선택하여이 두 가지 문제를 해결할 수 있습니다. 그런 다음 외부 로그인은 내부 계정 생성을위한 게이트웨이 일 수 있습니다 . 둘 이상의 로그인 방법으로 인증해야하는 경우 이미 로그인했다고 말할 수 있습니다. 외부 인증 공급자가 의존하는 것을 변경하면 사용자에게 내부 계정의 이름과 비밀번호를 제공하고 향후 로그인을위한 새로운 연결.

내가 생각한 문제를 해결했는지는 확실하지 않지만 구체적인 문제는 언급하지 않았습니다. 어느 쪽이든 내 대답이 도움이 되었기를 바랍니다.