1

나는 이것을 수개월 동안 읽었으며, 아래에 요약 한 내용에 모든 것이 수렴 ​​될 수있는 것처럼 보입니다. 나는 가장 이상적인에 도달하기 위해 노력하고있어 :쿠키를 사용하지 않고 권한 부여 코드를 사용 하시겠습니까?

  • OAuth2를
  • 오픈 ID 연결
  • SPA/모바일 클라이언트
  • JWT 위의 같은 은행 수준의 보안 품질을 가지고

솔루션 구성 요소가 관련되어 있습니다. 그래서 이것이 의미있는 것처럼 보입니다.

  • 서버 측 세션 및 쿠키를 사용하지 않고 Authorization Code Grant을 사용하십시오.이 OAuth 플로우는 암시 적 플로우보다 안전하기 때문에 사용하십시오.
  • 서버 측 세션 또는 쿠키를 만들지 마십시오. 클라이언트가 이전에 인증되었는지 여부를 식별하기 위해 쿠키를 기억하고있을 수도 있습니다. 이것은 스케일링 및 전반적인 단순성을 위해 더 좋습니다.
  • JWT/OpenID 연결 토큰을 클라이언트에 반환하면 클라이언트가이를 사용하여 API 요청을하고 클라이언트 내에서 권한 결정을 내릴 수 있습니다. (OAuth2 하이브리드 인증 코드 부여/암시 적 플로우가 무엇이라고 생각합니까?). JWT/OpenID 연결 토큰을 클라이언트 세션 저장소에 저장하십시오.
  • 수명이 짧은 JWT 토큰을 보유하고 사용자가 로그 아웃 할 때까지 새로 고침 토큰을 제공하십시오. 클라이언트는 시간 초과/클라이언트 측 세션이 만료되거나 사용자가 로그 아웃하지 않는 한 새로 고침 토큰을 자동으로받습니다. 새로 고침 토큰은 SPA/모바일 앱이 말하는/OAuth 클라이언트 인 에지 서버에서 가져와 제공합니다.
  • 로그 아웃 (또는 시간 초과)시 브라우저 세션 저장소에서 토큰을 제거하십시오.

이 모든 것이 미친가요? 무효화 토큰을 건너 뜁니다 만 토큰의 수명이 매우 짧고 클라이언트가 새로 고침 토큰을받을 수 있으면이 작업을 수행하는 것이 좋습니다. 나는 Spring-Boot/Spring Security와 Angular 4/5를 사용하여 이것을 구현하고 싶다. 내가 명백한 것을 놓친다면 궁금하다. 아니면 보안을 희생시키지 않으면 서 더 단순한 접근법이 있을까?

또한 "은행"수준의 보안 표준 검사를 통과 할 것이라고 생각하십니까?

+0

먼저 읽기 : https://stackoverflow.com/help/how-to-ask 하지만 사용 거라 생각 : 증명 한 라이브러리와 오픈 ID 연결 : https://openid.net/certification/ 을 OpenID Connect 모범 사례 준수 https://openid.net/specs/openid-connect-basic-1_0.html https://openid.net/specs/openid-connect-implicit-1_0.html – jwilleke

+0

예 나는 당신이 "How to ask"팁의 의미를 안다 - 나는 위의 접근 방식으로 조금 "상자 밖에서 뛰어 드는 것"을 느낀다. 그래서 나는 누군가 내가 생각할만한 미친 것을 본다. .. – Ole

답변

1

몇 가지

1.

당신은 브라우저와 같은 응용 프로그램 기밀을 할 수 없습니다 그것이 접수에 새로 고침 토큰을 보호 할 수 없습니다 becuase 이것은 기반 응용 프로그램

implicit flow을 사용할 필요가 밖으로 취소합니다. OAuth2.0 RFC도 흐름에 대해 설명합니다.

또한 OAuth2.0 Refresh token definition에 따라 새로 고침 토큰은 자격 증명 일종입니다.

새로 고침 토큰 따라서 broweser 기반 응용 프로그램에 대한 암시 적 흐름을 사용할 필요가 설명하는

10.4 of RFC6749 새로 고침 토큰 보안에 대한 자세한 설명 액세스 토큰을 얻기 위해 사용되는 자격 증명입니다.

2. 암시 적 흐름이

암시 부여 유형의 흐름을 사용하여, 새로 고침 토큰이 아닌 OAuth2.0에 RFC에서

토큰 새로 고침을 보내지 않습니다 는을 반환하는 액세스 토큰이 만료되면 권한 프로세스를 반복해야합니다.

그래서 액세스 토큰이 만료되면 새 토큰을 동일한 흐름을 통과하는 ID가 specficiation에 따라 vlaidate해야 사용

토큰

3. 설정했습니다. 아이디 토큰이 유효하면 사용자가 인증

4. API 중 하나를 사용하여 액세스 토큰 또는 사용자 ID 토큰,

두 가지 옵션을 호출합니다.

API 엔드 포인트와 통신하기 위해 액세스 토큰을 사용하는 것이 일반적입니다. 이것은 액세스 토큰의 의도 된 사용법입니다. API 엔드 포인트에서 액세스 토큰은 introspection endpoint (ID 공급자가 지원하는 경우)을 사용하여 무시할 수 있습니다.

그러나 ID 토큰 JWT는 무기명 토큰으로 사용할 수도 있습니다. 이를 수행하기 위해 API 엔드 포인트는 ID 토큰의 유효성을 검사하기 위해 워퍼 (warapper)가 필요합니다. This 블로그/문서에 고려해야 할 몇 가지 좋은 점이 있습니다.

+1

wrt. 1 : 기술적으로 권한 부여 코드 부여를 사용할 수 있지만 공개 클라이언트 만 사용할 수 있습니다. no client_secret –

+0

고맙습니다 - 훌륭한 대답입니다. 그리고 내가 질문 한 이유 중 하나를 설명합니다. 인증 코드 부여 흐름을 사용하고 싶지만 새로 고침 토큰, 세션 없음 (다른 세션 토큰/쿠키 없음) 및 리소스 서버 인증을 위해 jwt 토큰 또는 클라이언트/SPA로 새로 고침 토큰을 반환하는 중입니다. 이 유형의 시나리오는 OAuth2의 표준/청사진 인쇄본 밖에 있지만 권한 부여 서버를 약간 수정하여 구현할 수 있다고 생각합니다. – Ole

+0

"서버 세션없이 브라우저 기반 응용 프로그램에 권한 부여 코드 부여 방법을 사용하는 방법 ..." – Ole