우리는 여러 다른 클라이언트 (파서, 웹 응용 프로그램, 터치 응용 프로그램 등)에 데이터를 제공하는 중앙 RESTful 웹 서비스 응용 프로그램을 제공합니다. 클라이언트는 사용자, 일부 LDAP 및 다른 사용자를 인증하는 다른 수단을 가지고 있습니다. 그럼에도 불구하고 RESTful 응용 프로그램은 최종 사용자의 인증을 클라이언트에 남겨두고 요청을하는 클라이언트를 인증하기 만합니다. 클라이언트는 클라이언트가 RESTful 응용 프로그램에 액세스 할 수있는 허용 가능한 IP 주소 목록과 함께 LDAP에 사용자 이름과 암호를 갖습니다.RESTful 서비스를위한 두 가지 인증
다음은 까다로운 부분입니다. RESTful 응용 프로그램은 모든 요청을 최종 사용자의 사용자 이름으로 감사해야합니다. 또한 특정 상황 (클라이언트에 따라 다름)에서 RESTful 응용 프로그램에는 타사 응용 프로그램에 액세스하기위한 최종 사용자의 사용자 이름과 암호가 필요합니다. 따라서 클라이언트의 모든 요청에는 클라이언트 자체와 클라이언트에 액세스하는 최종 사용자에 대한 인증 자격 증명이 있습니다.
여기에 질문이옵니다. Basic Auth에 클라이언트의 자격 증명을 넣고 암호화 된 SALT 요청 매개 변수를 통해 최종 사용자의 자격 증명을 전달하는 것이 가장 좋을까요? 또는 클라이언트가 기본 인증 (즉, system ~ username : systempwd ~ userpwd)에 자격 증명의 두 세트를 모두 넣고 두 세트의 토큰을 구문 분석 한 다음 인증해야합니다. 아니면이 둘 중 하나보다 나은 다른 솔루션입니까?
도움이되는 정보에 대해 감사드립니다. 다음은 몇 가지주의 사항입니다. 하나는 모든 요청에 대해 인증을 수행해야하며 RESTful 웹 서비스 응용 프로그램에는 상태가 저장되지 않습니다. 두 가지로, 리소스를 업데이트하는 JSON 데이터가 포함 된 POST/PUT 페이로드의 경우 content-type이 "application/json"이어야하는 경우가 많습니다. 따라서 OAuth2 솔루션이 유스 케이스에 잘 맞는지 확신 할 수 없습니다. 다른 아이디어? 다시 한 번 도움을 주셔서 감사합니다. – Jimmy
중간 웹 서비스 응용 프로그램에 어떤 종류의 상태도 저장하지 않으면 모든 요청에 대해 클라이언트와 사용자 자격 증명을 모두 전달해야합니다. 이 경우 Authorization 헤더 (OAuth2 에뮬레이트)에 클라이언트 자격 증명을 붙여 모든 요청마다 사용자 자격 증명에 대한 JSON 속성을 예약합니다. 이런 식으로 : {user_credentials : {name : "John", pwd : "abcde"}, ... 다른 페이로드 ...}. 재미를보십시오 :-) –
글쎄, 그건 우리가 선택한 것이 아닙니다. RESTful 웹 서비스에서 종종 호출하는 타사 응용 프로그램에는 업데이트 (생성, 업데이트, 삭제)에 대한 최종 사용자의 사용자 이름/암호가 필요합니다. 따라서 OAuth2의 경우 액세스 토큰은 타사 소프트웨어에서 유효성 검사를 통과하기 위해 최종 사용자의 정확한 사용자 이름과 암호가 필요하기 때문에 유용하지 않습니다. 어제 제 3 자 소프트웨어가 OAuth로 이동할 계획이라고 들었습니다. 더 늦게 오는 것이 아니라는 희망이 있습니다. Jorn에게 감사드립니다. – Jimmy