2017-11-17 17 views
3

레거시 애플리케이션 (ASP.NET MVC 4 앱)을 OpenID Connect와 통합하려고합니다. 일단 OIDC 공급자로부터 id_token과 access_token을 얻으면 저장해야합니다. 전형적으로 그들은 클라이언트 측에서 서버 측으로 'over the wire'로 보내야합니다. 왜냐하면 서버 측에서는 id_token을 처리하여 어떤 사용자가 요청을했는지 판단해야하기 때문입니다. 내 애플리케이션에서 access_token을 처리하지 못했습니다. JWT Bearer 인증을 요구하는 API를 요청할 때까지는 애플리케이션에 저장됩니다.OpenID Connect id_token과 access_token이 HTTP 전용으로 표시된 쿠키에 안전하게 저장할 수 있습니까?

내가 보는 방법은 id_token과 access_token이 클라이언트와 서버 중 어느 쪽에서든지 (헤더 또는 쿠키이든) 전송된다는 것입니다. id_token 및 access_token을 HTTP 전용으로 표시된 쿠키에 안전하게 저장할 수 있습니까?

편집 : 내 시나리오에 대한 정보를 추가해야합니다.

1) 내 애플리케이션은 항상 HTTPS를 사용하며 모든 쿠키는 안전한 것으로 표시됩니다. 이것은 MITM (Man In The Middle) 취약점을 제거합니다.

2) 모든 PUT, POST 및 DELETE 요청은 ASP.NET의 위조 토큰 클래스를 사용합니다. 이는 XSRF를 보호합니다.

3) XSS 취약점을 제거하는 ASP.NET 라이브러리를 사용하여 모든 입력이 이스케이프되고 삭제됩니다.

4) id_token을 포함하는 쿠키는 http 전용으로 표시되어 클라이언트 측에서 쿠키를 읽고 액세스 할 수 없도록합니다.

답변

0

쿠키에 토큰을 저장하지 마십시오. 이상적으로 액세스 토큰은 클라이언트의 메모리에 저장됩니다. 어느 곳에서나 잠재적 인 취약점에 노출 될 수 있습니다.

사양 "OAuth 2.0 위협 모델 및 보안 고려 사항"은 액세스 토큰 관련 위험 및 취약점에 대해 설명합니다. 응용 프로그램에서 인증을 구현하는 경우

사실, 내가보기 엔 당신이 좋습니다 특히, 나는 액세스 토큰에 대해 이야기 다음 섹션을 읽는 것이 좋습니다 전체 사양을 읽고 OAuth 2.0 사용시 발생할 수있는 위험을 파악하십시오.

1

HttpOnly는 클라이언트 측 스크립트에서이 쿠키에 액세스해서는 안되며 브라우저가 지원하는 경우에만 true라는 것을 브라우저에 알리는 플래그입니다. 여기에서 자세한 정보를 찾을 수 있습니다 : https://www.owasp.org/index.php/HttpOnly 또한 OWASP 웹 사이트에 나와있는 것과 같은 문제에 대한 모범 사례에 관한 문서가 있으므로 잠시 생각해보십시오.