RESTful 서비스에 대한 사용자 인증

Question

현재 고객이 있습니다. 그들에게 RESTful 서비스 (앱을 통해)를 통해 그들 자신에 대한 특정 세부 사항에 대한 액세스 권한을 부여하고자합니다.

고객에게 가능한 한 적은 번거 로움을주고 싶습니다. 그래서 각 고객에 대해 UUID를 생성 한 다음 UUID를 ID로 제공하여 REST에 액세스하게 할 생각입니다.

예 : http://www.example.org/rest/value/UUID 또는 http://www.example.org/rest/value이며 TLS를 통한 HTTP 기본 인증으로 UUID가 사용됩니다.

내 걱정은 보안입니다. 이 개념들 중 일부에 익숙하지 않다는 것을 명심하십시오. 특정 고객이되는 것을 증명하는 UUID를 사용하여 주된 관심사는 무엇입니까?

위의 시나리오가 이론적으로 전송 중에 UUID를 숨길 수 있다면 UUID를 스니핑하는 누군가에게 공개해야합니다.

나는 UUID가 사람이 읽을 수있는 것은 아니지만 URL/QR/유사를 통한 입력이라고 생각합니다.

Answer 1

유효한 사용자의 고정 식별자로 UUID를 사용하는 것은 위험합니다. UUID는 be unique, not random으로 생성됩니다. 공격자가 합법적 인 UUID를 가지고 있으면 다른 사용자의 식별자를 추측하려고 시도 할 수 있습니다.

고정 식별자는 쉽게 유출 될 수도 있습니다. HTTPS를 사용하여 전송 채널에서 식별자를 숨기더라도 사용자가 전자 메일에 링크를 복사하거나 다른 사람이 화면에서 식별자를 낙서 할 위험이 여전히 있습니다.

HTTP 헤더가 링크에 반영되거나 화면에 표시되지 않으므로 HTTP 헤더에서 식별자를 보내는 것이 더 안전합니다. 그러나 식별자가 유출 된 경우 공격자는 식별자가 도용 된 사용자를 쉽게 가장 할 수 있습니다.

그래서 대부분의 인증 시스템은 한정된 시간 동안 유효한 (세션 -) 식별자 또는 토큰을 생성합니다. 도난당한 경우 사용할 수있는 제한된 창이 있습니다.

실행중인 플랫폼이나 REST 서비스가 인터넷이나 인트라넷에서 액세스되는지 여부는 언급하지 않았습니다. 후자의 경우 Windows Active Directory 도메인에서 Integrated Windows Authentication과 같은 것 (사용자의 로그온 세션을 사용하는 것)이 가장 번거 롭습니다.

그렇지 않으면 아마도 JWT based authentication 메커니즘을 살펴 봐야합니다.

Answer 2

OpenID Connect 1.0 사양을 기반으로 인증 레이어를 구현하는 것이 좋습니다. 인증 된 세션의 공급자는이 경우 응용 프로그램 외부에 있습니다. OpenID 사양은 확장 가능하므로 원하는 경우 암호화를 사용할 수 있습니다.

각 고객의 요구에 따라 UUID를 생성한다고해서 보안 자체가 보장되는 것은 아닙니다. HTTP 대화에서 UUID 또는 기타 일반 텍스트 정보를 알아내는 것은 어렵지 않습니다. Open ID Connect는 응용 프로그램이 인증 된 세션을 설정하고 고유 한 세션 식별자를 사용하여 이후의 각 요청을 확인하는 방법을 정의한다는 점에서 다릅니다.

희망 사항이 도움이되기를 바랍니다. 작동 방식에 대한 추가 정보가 있습니다 http://openid.net/connect/faq/